Some advantages: 1. If it's a server login that checks against and explicit group of users, then it's more secure than using CF. Anything in that directory is now protected, not just CFM pages.
2. You don't have to do any coding in your app to make login screens, store passwords, cookie security etc. 3. Centralized administration of logins. If the server's authentication is checking against say an LDAP server, now all apps within an organization can use a common login instead of creating multiple databases of users and passwords for each app. This is especially useful in intranet situations where there are likely logins for systems other than just the web. 4. If you have a large pool of logins, and you have the CF app check against a sub-group of those users by comparing the username you want to the cgi.remote_user, then you are only secure for CF but you've still saved yourself considerable administrative work to maintain yet another set of logins. 5. Developers now don't know or even need, or should have, access to user's passwords. In a normal database table, the developer of the app can just go in and look at people's passwords. Here it's abstracted out from the developer's "need to know". Some possible disadvantages: 1. Requires more architectural work such as maintaining an LDAP server or at least server level logins. 2. Takes some control of the app out of the developer's hands and may require more calls to server admins to lock down a directory to a group. 3. A one-login situation opens up new questions for security. 4. If you are using something like an LDAP server to store the login information, it becomes much harder to build user-initiated password reminder/lookup features. Or even to build a login screen into the look/feel of your web site. 5. Best for intranets where users are already in a system. It's not as conducive for public sites with simple user logins for something like a forum. I'm certainly no expert on this. It's just something our organization has been moving to and so far it's been a really nice way to do things. I don't administer the servers, and I'm not even a hotshot CF dev here. But in our situation with a very large organization and hundreds of apps, anything to make our development faster, the server more secure, and the user's list of passwords shorter is a boon. -Kevin > -----Original Message----- > From: Kola Oyedeji [mailto:[EMAIL PROTECTED]] > Sent: Sunday, December 15, 2002 1:56 PM > To: CF-Talk > Subject: RE: Login/Password screen > > > Kevin > > Thanks for the explanation. I didn't realise this was so simple. What > advantage (if any) does rolling your own login page in coldfusion > have over > this? > > Kola > > > >-----Original Message----- > > >From: Kevin Graeme [mailto:[EMAIL PROTECTED]] > > >Sent: 13 December 2002 21:45 > > >To: CF-Talk > > >Subject: RE: Login/Password screen > > > > > > > > >The server sets it when the person authenticates to the server > > >login. So you > > >just define the directory as restricted in the web server > configuration, > > >then when a person requests anything in that directory or > lower, the web > > >server intercepts it before anything else does and asks for a login. > > > > > >The CF app can then read the #cgi.remote_user# variable and > compare that > > >against a database of users for personalization if you like. > > > > > >-Kevin > > > > > >> -----Original Message----- > > >> From: Kola Oyedeji [mailto:[EMAIL PROTECTED]] > > >> Sent: Friday, December 13, 2002 11:19 AM > > >> To: CF-Talk > > >> Subject: RE: Login/Password screen > > >> > > >> > > >> Kevin > > >> > > >> How is CGi.remote_user set? > > >> > > >> > > >> Kola > > >> > > >> >> -----Original Message----- > > >> >> From: Kevin Graeme [mailto:[EMAIL PROTECTED]] > > >> >> Sent: 13 December 2002 16:04 > > >> >> To: CF-Talk > > >> >> Subject: RE: Login/Password screen > > >> >> > > >> >> It's not a browser issue so much as on the server. The > server stores > > >> a > > >> >> set > > >> >> of cgi.something variables that can be asked for by CF. We used to > > >> use > > >> >> cgi.auth_user, but when we switched over to Apache, that wasn't a > > >> valid > > >> >> cgi > > >> >> variable anymore. Now we use cgi.remote_user. > > >> >> > > >> >> -Kevin > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: Kola Oyedeji [mailto:[EMAIL PROTECTED]] > > >> >> > Sent: Friday, December 13, 2002 9:36 AM > > >> >> > To: CF-Talk > > >> >> > Subject: RE: Login/Password screen > > >> >> > > > >> >> > > > >> >> > That's a good idea, does cgi.remoteuser work with all major > > >> browsers or > > >> >> > just i.e.? > > >> >> > > > >> >> > Thanks > > >> >> > Kola > > >> >> > > > >> >> > >> -----Original Message----- > > >> >> > >> From: Kevin Graeme [mailto:[EMAIL PROTECTED]] > > >> >> > >> Sent: 13 December 2002 14:33 > > >> >> > >> To: CF-Talk > > >> >> > >> Subject: RE: Login/Password screen > > >> >> > >> > > >> >> > >> Keep in mind that a CF based authentication system is only > > >> checked > > >> >> > >> against > > >> >> > >> if the user hits a CFM page. That's fine for certain types of > > >> >> > projects, > > >> >> > >> but > > >> >> > >> not for actual file security. So if you have a directory of > > >> images > > >> >> in > > >> >> > the > > >> >> > >> "secure" area, a person could link directly to an image and > > >> bypass > > >> >> > the > > >> >> > >> login > > >> >> > >> altogether because a .gif doesn't reference the > Application.cfm > > >> >> > first. > > >> >> > >> > > >> >> > >> We've been using the server level authentication and > then using > > >> cf > > >> >> to > > >> >> > >> check > > >> >> > >> against the cgi.remote_user to see who it is. That means that > > >> ANY > > >> >> > attempt > > >> >> > >> to > > >> >> > >> get in at that protected area has to be authenticated against > > >> with > > >> >> > the > > >> >> > >> server. > > >> >> > >> > > >> >> > >> -Kevin > > >> >> > >> > > >> >> > >> > -----Original Message----- > > >> >> > >> > From: FlashGuy [mailto:[EMAIL PROTECTED]] > > >> >> > >> > Sent: Friday, December 13, 2002 6:43 AM > > >> >> > >> > To: CF-Talk > > >> >> > >> > Subject: Login/Password screen > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > Hi, > > >> >> > >> > > > >> >> > >> > I know there are alot of custom tags out there that will do > > >> what > > >> >> > >> > I'm looking for but I want the best one. So this is why I'm > > >> >> > >> > asking all of you hoping you've had > > >> >> > >> > some experience with some of them. I'd like > everything stored > > >> in > > >> >> > >> > a database. I know some don't do that. Bascially, once the > > >> user > > >> >> > >> > enters in their > > >> >> > >> > username/password they are redirected to a URL on > the server > > >> >> > >> > based on the authentication. > > >> >> > >> > > > >> >> > >> > I have one called <CF_EzPassword> but was > wondering if there > > >> are > > >> >> > >> > any better ones? > > >> >> > >> > > > >> >> > >> > Thanks > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > --------------------------------------------------- > > >> >> > >> > Colonel Nathan R. Jessop > > >> >> > >> > Commanding Officer > > >> >> > >> > Marine Ground Forces > > >> >> > >> > Guatanamo Bay, Cuba > > >> >> > >> > --------------------------------------------------- > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > >> >> > > > >> >> > > > >> >> > > >> > > >> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
