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 <FONT COLOR=BLUE>""</FONT>;
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.