Session problems

[MorganGreylock]

Ok folks, I've really confused myself here. I've got a site
that uses session variables to keep track of who is logged
in for various purposes. People can update their own info,
submit requests for various things, etc. My problem is that
it seems that my session variables are persisting through
browser closes. I close all instances of my browser, and
I can go to an otherwise secure (requiring login) page because
the session variable it is looking for still exists even
though I closed the browser.

I'm confused on domain cookies, client cookies, etc., and
how to use them. I had some of them turned on for a while, but here is what my application.cfm looks like now:

<cfapplication name=&quot;testapp&quot;
clientmanagement=&quot;yes&quot;
sessionmanagement=&quot;yes&quot;
setclientcookies=&quot;yes&quot;
setdomaincookies=&quot;no&quot;
sessiontimeout=&quot;#CreateTimeSpan(0,1,0,0)#&quot;
applicationtimeout=&quot;#CreateTimeSpan(1,0,0,0)#&quot;
clientstorage=&quot;cookie&quot;>

To be honest, I'm hazy on the difference between client
and session. I want people to be able to login from anywhere, not caring what computer they are using. (I assume thats what client management is, so should I turn that off?)

I would use a logout feature, but I'm sure none (or very
few) of our users would actually use it. They do, however,
close their browsers when they are finished, as that has
been beaten into their heads for years.

Any help is appreciated,

MG

 

[csteinhilber]

Ehhhh... no, not quite. SESSION and CLIENT both are machine (cookie) dependent. You'll never be able to have people &quot;login from anywhere, not caring what computer they're using&quot;.

The difference between SESSION and CLIENT scopes is that SESSIONs disappear when the session has expired. CLIENT variables persist across browser sessions... though, as I said, they're still dependent on the value of a cookie on the current machine. In fact... I can't think of a way that you'd be able to have CLIENT vars shared across machines... short of copying the cookies manually from one machine to the other... and even then I'm not sure it'd work.


Your session issue, though, is because you're setting a session timeout of 1 day. This is pretty typical, since you really want something that's long enough so that it doesn't time out while the user is still on the site, but inactive (say, reading a long page of text), and short enough that you're not keeping their session open beyond a reasonable expectation (and opening up a security risk).

ColdFusion (or any web/app server) never really gets notified when the user shuts down their browser. HTTP just doesn't have that level of interactive commnunication. Thus, the server doesn't really know if a user has left the site, shut down, or is just taking a break to take an important phone call. So, in practice, ColdFusion just needs to sit there and wait for the next request from that same session/user. If it doesn't receive one within the specified timeout period, then it declares that the session has ended. You could certainly set the session timeout to be something shorter if you like... and that would help with your issue (though it might cause other problems later).

In order to explicitly log out (end the session), you'd either need to provide a logout button, or do something with javascript during the page's onUnload event that checks where the user is going (if anywhere) and logs out accordingly (not an easy task, but it's been done).


However... generally cookies are unique to the user that's actually logged into the workstation (your employer makes everyone log in and out of it's computers, doesn't it??)... so if you're on a page on your site, and you log out of the workstation, ColdFusion will keep your session open for you for as long as you specify... but if someone else happens to log onto that same workstation, they'll have a different cookie, and ColdFusion will consider it a different session anyway... so they'll have a whole different set of session variables. Then, if they log out, and you log back in before the session timeout, you should still find your original session open.

At least, that's the way it's supposed to work.



-Carl

 

[MorganGreylock]

Carl,

Thanks a lot for the response... it was very informative.
Unfortunately the primary users of this site are people who
are not employed here, but rather students, and pharmacists
around the state, neither of which I can dictate how they use
the site. I'm lucky if these people can remember what their
own email address is. Thats the main reason why I decided not
to use a logout feature, because I know they would never use
it, and I definitely couldn't count on that.

I was always under the impression that the session was closed
when the browser was closed. I had previously set my session
timeout to 20 or 30 minutes, but some people were complaining
that they didn't have enough time to fill out the 30-35
text boxes before the session expired, so naturally I
overcompensated. =)

I'll play around with the session timeout and see if I can't
get that to work better for me.

Thanks again,
MG

 

[WestSide2003]

Hi,

Not sure if this will work for you, but does for me..

Try putting this at the very bottom of your Application.cfm file

<!--- Reset the CFID and CFToken cookies to expire session and client variables after the user's browser closes. --->
<CFSET Cookie.CFID = SESSION.CFID>
<CFSET Cookie.CFTOKEN = SESSION.CFToken>

Then clear your browser cookies, etc... and see what happens.

Works for me.. if I close my browser from any page in my site, it kills the session..

-WestSide

 

[philhege]

WestSide2003,

I know this works, because I use it on my site, but do you or anyone else have a lucid, concise explanation of how and why this works?

Phil Hegedusich
Senior Web Developer
IIMAK

http://www.iimak.com

-----------
Boy howdy, my Liberal Studies degree really prepared me for this....

 

[csteinhilber]

You're basically telling the cookie to expire immediately (effectively clearing/deleting it).


-Carl

 

[philhege]

I don't see how setting the CFID and CFTOKEN attributes has anything to do with an expiration time. They're numbers, not timestamps. A little more exposition, please?

Phil Hegedusich
Senior Web Developer
IIMAK

http://www.iimak.com

-----------
Boy howdy, my Liberal Studies degree really prepared me for this....

 

[csteinhilber]

Sorry... I'm wasn't terribly clear... must be this flu.

<CFSET Cookie.CFID = SESSION.CFID>
<CFSET Cookie.CFTOKEN =  SESSION.CFToken>

clears the persisent cookies for these values, and rewrites them as per-session cookies (cookies that are only kept around as long as the browser is open).

this is because the above code essentially equates to:

  <CFCOOKIE name=&quot;CFID&quot; value=&quot;#SESSION.CFID#&quot;>
  <CFCOOKIE name=&quot;CFTOKEN&quot; value=&quot;#SESSION.CFTOKEN#&quot;>

(which is the legal way it's supposed to be written by the way... though the first way works)

Setting a cookie without specifying an expiry sets it up as a &quot;per-session&quot; cookie by default.


To understand what this means, you actually have to look at what ColdFusion does to make the SESSION possible.

See, there is no such thing as &quot;session&quot; in traditional HTTP. When the browser requests a page, the web server responds by supplying that page... but it really doesn't have the time nor inclination to see what the browser is doing after that. It happily goes on responding to other requests. It doesn't really even know if two requests within a given timespan are from the same browser.

So, on an initial request, ColdFusion stores a couple of cookies... CFID and CFTOKEN (as well as CFMAGIC). This is so that, no matter what happens with the browser after that, ColdFusion will be able to recognize the browser as a unique user. Each successive request (requests that are processed by ColdFusion anyway) checks the values of these cookies, matches them against it's internal database, and feeds off the session variables that are appropriate for that user.

These cookies are ordinarily set up as &quot;persistent&quot; cookies... meaning they could hang around forever if you wanted them to. Usually, they hang around for 20 minutes (default)... configurable in the CFAPPLICATION tag by the SESSIONTIMEOUT attribute; setting SESSIONTIMEOUT to CreateTimeSpan(0,4,0,0) essentially writes those two cookies as:

  <CFCOOKIE name=&quot;CFID&quot; ... expires=&quot;4 hours from now&quot;>
  <CFCOOKIE name=&quot;CFTOKEN&quot; ...  expires=&quot;4 hours from now&quot;>

By rewritting these cookies with no EXPIRES attribute (as above), you tell the browser that you want it to be the maintainer of the cookie, and you want it to automatically flush these cookies when it shut down.

This would probably be the best solution in your situation.



-Carl

 

[csteinhilber]

Oh gawd... that's not a whole lot better than the first explanation! Darn Nyquil!

I'm also reminded that you should use a lock around the SESSION scope access.

So... the short answer...

<CFLOCK SCOPE=&quot;SESSION&quot; TYPE=&quot;READONLY&quot; TIMEOUT=&quot;5&quot;>
     <CFCOOKIE NAME=&quot;CFID&quot; VALUE=&quot;#SESSION.CFID#&quot;>
     <CFCOOKIE NAME=&quot;CFTOKEN&quot; VALUE=&quot;#SESSION.CFTOKEN#&quot;>
</CFLOCK>

resets the normally persistent session identifier cookies as &quot;per-session&quot; or &quot;session-only&quot; cookies instead... which will be automatically deleted if the user shuts down the browser.


Here's the official word:

http://www.macromedia.com/support/dreamweaver/ts/documents/cfauthentication.htm

-Carl

 

[philhege]

Thanks, Carl. Nyquil or not, that makes sense to me, and thanks for the link.

Phil Hegedusich
Senior Web Developer
IIMAK

http://www.iimak.com

-----------
Boy howdy, my Liberal Studies degree really prepared me for this....