1 Reply Latest reply on Sep 11, 2006 11:14 AM by tclaremont


      Hi all,
      Access to my intranet is authenticated externally using a webagent. When successful, the webagent passes the username back to the environment, so I know the user is allowed access to the site home page. I need to further restrict (authorize) access to sub-directories (applications), and can access AD to check a user's group membership using <cfldap> and the username passed in from the webagent in the "filter" attribute. At this point I would like to log the user into the site using the security framework. Typically, <cflogin> checks whether the "cflogin" objects already exist, and if not, a login form is presented, and j_username and j_password posted so that CF can create the cflogin structures that include cflogin.name and cflogin.password. Since I already know the user has been authenticated, I do not want to present a second login screen, but rather want to log the user directly into the security framework after the user's groups (roles) are pulled from AD.

      My question (finally) is whether the "cflogin" structures must exist before I can log a user in using <cfloginuser>. If so, can I create the necessary structures programatically and populate them without going through a login screen and posting j_username/j_password? If anyone has done this, please let me know. Thanks in advance.

        • 1. Re: CFLOGIN
          tclaremont Level 2
          If you are using IIS and Windows Integrated Authentication, just use

          <CFSET UserName = #CGI.AUTH_USER#>

          Then, if the UserName is undefined, then the user has not been authenticated on the network, and you can CFLOCATION them off to an Access Denied page.

          <cfif NOT IsDefined ("UserName")>
          <cflocation url="AccessDenied.cfm">

          There is no need to store or maintain passwords, because as long as they are authenticated on the domain then all is good.

          If you place the code shown above in your Application.cfm(cfc) it will get called on every page. What this helps with is people who want to alter the variable through the address bar. They can't do that if the code is executed with each page request.

          On my intranet site, I have a database table with username, and a list of directories on my website. If the current user has rights in the current directory, the user is allowed to view the page. If they do NOT have rights, they are CFLOCATION'ed off to an Access Request Page.