This content has been marked as final. Show 5 replies
> This effectively makes the cflogin tag useless. It would be better for one to simply check for the existence of a session variable to determine if a user is still logged in.
I don't hink so. Don't forget that login status can also be stored in a cookie by means of loginStorage. To determine whether a user is still logged in, use the function
Yep, you are right. I've been using GetAuthUser(). The problem (and I'd like to hear about how people handle this), is that GetAuthUser() can expire independently of the session variables, particularly if using NTLM or LDAP.
For example, set the session timeout to 1 minute. CFLOGIN (and I assume GetAuthUser() also) will report that the user is still logged in. This seems like a ridiculous situation. But consider the case where using NTLM or LDAP for authentication. One can be logged in as long as the browser is open, while the session variable often are given a shorter limit.
How do people handle this? Do they use J2EE sessions?
GetAuthUser() can expire independently of the session
I think that that is desired behaviour. The function is not directly related to session. It is related to cflogin and, in turn, login details can be stored in the session scope. The timeout logic is then
timed-out-session implies timed-out-login.
When the session expires, so does login, and getAuthUser() returns an empty string. However, session outlives login.
So, the value you set for the sessiontimeout value should be higher than the idletimeout value in the cflogin tag. You may set it lower, but that will achieve nothing.
One can be logged in as long as the browser is open, while the session
variable often are given a shorter limit.
Possible. The default loginStorage is cookie, not session.
I've been researching a similar issue and even though this topic is well over a year old I figured I would chime in.
I don't know if this behavior is a "bug" or just part of the design but I agree with dichi66. It is typical to associate a user's login status with their session, so placing <cflogin> and session variables in two different "idle contexts" seems counter intuitive. Granted <cflogin> has been around for years so it's either working for most developers or developers are simply not using it in lieu of "rolling-their-own" security logic.
I've also noticed the session scope and <cflogin> have two different concepts on what constitutes "idle time". It appears <cflogin> requires an actual page refresh to remain active while the session scope simply requires server activity. With a greater usage of technologies such as Ajax I see this becoming an larger issue.
Seems like a hack but it works... Don't know if this info is helpful at all but there you have it. :)