I've been a fan of CFLOGIN for quite some time. Both BlogCFC and Galleon use it - as do most of my applications. But the troubles and limitations with the framework are really starting to get to me.
If you don't remember, there were various security issues with the framework from CFMX 6 to 6.1 (even with the updater). There are also some things that are missing that don't make sense: isAuthenticated (don't even get me started about how you couldn't write a UDF with that name till CFMX7), getUserGroups, etc. Of course, you could work your way around the things that were missing - but the security problems simply made CFLOGIN unuseable.
I had a user report that they had an issue using Galleon under IIS. Turns out - their IIS directory had security applied to it. CFLOGIN, by default, will "auto-detect" if you are logged in via the web server. In this case, my app thought the user was logged in, when in reality, they had never actually logged into the application.
The bug (which is my fault) I believe lies here:
return getAuthUser() neq "";
}
This is the code I use to check and see if a user is logged on or not. When the user logged in using IIS, the application thought there were logged on. So, I'm thinking the fix is to simply add a session flag and check for that. I normally don't ever access session (or application, server, etc) variables from a UDF, but this is a good example (I think) of when breaking the rules is ok.
The next problem is the cflogin block itself. I need to check and see if the code inside the cflogin block is run when the user has authenticated in IIS. If not, I need to rewrite the logic and not really on the "conditional" nature of the cflogin block.
So - I kinda ranted on the cflogin feature here - and I don't really intend to. I'm going to work with the user and see if we can get Galleon playing nicely with his IIS secured directory. When that happens, or if I have to rip out cflogin entirely, I'll post again.
Archived Comments
I had the same sort of troubles back when I first started using cflogin back in 6.1. I ended up writing my own login.cfc that took care of everything, and I've been using it ever since. I plan on releasing it in COAL.
I'm not a fan of rewriting existing functionality in a given product or platform, but I think the Session handling in CF is one of it's weakest points. It's a rare case where I decided rolling my own was a better choice than trying to work around it's limitations/burdens. Especially after grinding my teeth on non-locked Session calls in CF 3-5 in other peoples code many times in the early days of my CF career...
it's only useful if you want to lock down remote methods... but now I'm of the opinion that you should be doing even THAT yourself .
I really wanted to use cflogin -- i did...i had such high hopes that it would be an easy architecture to use -- until I realized that my user's passwords with periods and apostrophes were being truncated. To this day i don't know if it was cflogin or the J2EE, but I had to give up and roll my own.
So now I have a pleasant CFC that will authenticate via three methods (LDAP, "local" (read database), and X.509). Yay! And yes, I did have to pull session scope in the CFC for one piece of information.
Call me old fasion, but I never really like the concept of CFLOGIN. I guess it because I have always used client variables for login information. CFLOGIN just felt really klunky from the beginning.
I have never used session variables before, and I just don't like the fact of putting authenication info into a cookie. I like the fact that client variables use cookies to tie the person to the session, can be clustered across multiple servers since the information is stored in a DB and not in memory and the actually content of the client variable is stored in the database so the enduser can't get at it.
Yeah I know you have to add an extra step of using CFWDDX to store and pull the info from the database, but after like 2 times of doing it, it just becomes habit.
Tony - I have some problems with your post (respectfully :)
You say you don't like putting auth. info in a cookie - but session vars - like client vars - don't put anything in the cookie except for the 'marker'. So client.password is just as secure as session.password. Now - you are correct in that client vars give you the ability to work over a cluster, although sessions can be forced to once machine in a cluster.
Ray,
You could add a role during your login process and perform a role check.
<cfif GetAuthUser() neq "" and not IsUserInRole("MyLogin")>
If the role doesn't exist, it's an auto-login from NT.
Ray,
Actually I didn't mean to state that about session variables. I know they don't put the information into the session cookies. I meant to say that I don't like the idea of just using cookies (not session variables cookie or client variables cookie, just cookies) and putting authentication information in them. I know some people that acutally do this. It was just my poor grammer and not fully explaining what I meant that got mixed up.
:)
Tony: Cool beans.