Using Session Variables for User Login - sometimes they don't persist... what am I doing wrong?

Report · Jun 22, 2010

Hi all,

I'm running a site that requires user login. I approached the building of this site as almost a complete newb to CF (and dynamic coding in general), and it's been a great learing experience (with lots of help from you guys).

However, I guess I never learned the correct way to handle a user login. It seemed to me that I could just test the user-entered credentials against those stored in a database, then set a session variable containg that user's record number. Then, not only would I have an easy way of knowing who this user was and therefore what info to serve him, but I could test for the existence of a valid login on every page in the protected folder, by adding this code to my application.cfc in that folder:

...and it goes on to run a query and verify that the session.username and session.password match for the store defined by session.storeID. If not, all session variables are cleared and it bounces you back to the login page. When the user clicks Logout, all I do is delete all the session variables.

This seemed to work great for like a year, but lately I've been getting reports that the login doesn't seem to persist for longer than approx. 20 minutes of inactivity. You can see I specified session variables to remain active for 8 hours (I know that seems like a drastically long login, but it's what's necessary for this application). I've only gotten this report from a few people, and I myself can't seem to duplicate it... I've tested an inactive login for 45 minutes now and it held.

SO: any reason you can think of why session variables would be spontaneously clearing for some people? Would having your router reset its IP address invalidate the session or something? Also, the problem seemed to begin appearing after my host upgraded all their servers to CF9... could there be any relation?

And on a more general note... did I go about this completely the wrong way to begin with? If so, what's the standard way to manage a login?

Lots of questions, I know... thanks very much for any answers or suggestions!

Joe

Report · Jun 23, 2010

Two possible things to investigate first.

1) There are settings in the ColdFusion administrator for both a default and maximum length of session and application variables. It is possible that your hosting provider set a maximum of 20 minutes. Now this should affect everybody, but it is good to check.

2) Session state is dependant on cookies. If a user has anything that causes cookies to not proplerly be sent and received, then session state can not be maintained. Cookies can be messed with by users clearing the browser, proxies, firewalls, anti-virus|malware tools, etc.

In Response To ilssac · Jun 23, 2010

Hi Ian, thanks for the reply.

I've checked with my server admin, and while the default timeout is 20 minutes, it seems my overriding of this in my Application.cfc is working - at least for most of us. I'll double check with him about the maximum session lenght, but again - seems to work ok most of the time.

I was thinking along the same lines, of a firewall or anti-malware software clearing the cookies. I also wondered about a user's router releasing/resetting the IP. Would this clear a session?

Instead of troubleshooting this particular problem, would it just be easier for me to go about this a different way? Is there a way to maintain session information WITHOUT worrying about cookies? Put another way - if you were building an application like this, what technique would you use?

Thanks...

Joe

In Response To StearmanDriver · Jun 23, 2010

Unfortunately this is the nature of HTTP web applications. There is NO state maintained from HTTP request to request. This is by design in the HTTP protocol specifications.

ColdFusion provides two methods to circumvent this limitation. Each method has limitations and caveats. They both rely on the passing of tokens between the client and the server with every request. These tokens can be passed as cookies OR URL (GET) variables. You are using the cookie method, which is the simpler and most common. You may be experiencing the limitation of this method. If something happens to the cookies the session can be lost.

You could pass the (CFID & CFTOKEN) OR JESSIONID tokens through the URL query string with every request. This requires one to add these values to every link, form action, cflocation or other request path in our application. ColdFusion provides the session.urltoken variable to make this easier to do. The tokens will be visible to the user. Also if the links with an individual token is share with other users, via e-mail, chat, social networks, etc and one of these users utilize the link during the life of a session (8 hours apparently in your case). Then that user will access the session of the original user.

Cookie session management is by far the most common choice by CF developers. If these methods do not meet your needs you would need to go beyond the HTTP limitations of web applications. One might be able to accomplish this with a Flex|Air|Flash applications that can be configured to use a continuous connection to the server. Thus not suffer the stateless nature of the normal HTTP request-response cycle.

I do not know if a router resetting would cause cookies to be discarded or otherwise invalidated. But I would not think it is beyond the relm of possibilities.

In Response To ilssac · Jun 23, 2010

Ian,

Thanks very much - very helpful information.

Sounds like passing the tokens in every request is probably the way to go for this. I don't think it's likely that any users will be sharing links, unless they actually intend for the recipient to see their info anyway.

Is that all I would have to do, is add the tokens to every path? Would that guarantee that all the session variables would remain valid until timeout or being cleared?

Again, thanks, you've been really helpful.

Joe

On Jun 23, 2010 4:37 PM, Ian Skinner <forums@adobe.com> wrote:

Unfortunately this is the nature of HTTP web applications. There is NO state maintained from HTTP request to request. This is by design in the HTTP protocol specifications.

ColdFusion provides two methods to circumvent this limitation. Each method has limitations and caveats. They both rely on the passing of tokens between the client and the server with every request. These tokens can be passed as cookies OR URL (GET) variables. You are using the cookie method, which is the simpler and most common. You may be experiencing the limitation of this method. If something happens to the cookies the session can be lost.

You could pass the (CFID & CFTOKEN) OR JESSIONID tokens through the URL query string with every request. This requires one to add these values to every link, form action, cflocation or other request path in our application. ColdFusion provides the session.urltoken variable to make this easier to do. The tokens will be visible to the user. Also if the links with an individual token is share with other users, via e-mail, chat, social networks, etc and one of these users utilize the link during the life of a session (8 hours apparently in your case). Then that user will access the session of the original user.

Cookie session management is by far the most common choice by CF developers. If these methods do not meet your needs you would need to go beyond the HTTP limitations of web applications. One might be able to accomplish this with a Flex|Air|Flash applications that can be configured to use a continuous connection to the server. Thus not suffer the stateless nature of the normal HTTP request-response cycle.

I do not know if a router resetting would cause cookies to be discarded or otherwise invalidated. But I would not think it is beyond the relm of possibilities.

In Response To StearmanDriver · Jun 23, 2010

Just to keep your language clear, using cookie OR the url query string both pass the tokens with every request.

But to answer your underlining question. Yes, if you rework your applicaiton to use the query string, this will maintain session state the similarly as cookies did. It can be quite a task to rework an existing applicaiton because you need to modify every internal link, form action, frame, img src, css href, javascript source or any line of code that makes a request to a CFML resource. I though things in there that seldom request a CFML resource like the img src, but they sometimes do. And if they do, they need the token.

As to users sharing links, they seldom understand the relationship between the links and tokens and their sessions. So just be clear and careful with your urers so that when and if they come forward with this sharing problem, you can point to where you explained how and why that would happen.

I try to never underestimate the troubles users can cause me.

In Response To ilssac · Jun 23, 2010

Again, Ian, thank you.

I will definitely look into this. As far as the mechanics of accomplishing it, do I need to designate somewhere that I'm switching from the cookie method to the URL variable method, or would just adding the url variables to every url without aking further action be enough?

Also... What happens if some urls have the variables attached and others don't? Would it fall back on looking for a cookie at that point? Just thinking that would allow me to make the changeover a little at a time, as I have time.

Thanks again!

-- Sent from my Palm Pre

On Jun 23, 2010 6:28 PM, Ian Skinner <forums@adobe.com> wrote:

Just to keep your language clear, using cookie OR the url query string both pass the tokens with every request.

But to answer your underlining question. Yes, if you rework your applicaiton to use the query string, this will maintain session state the similarly as cookies did. It can be quite a task to rework an existing applicaiton because you need to modify every internal link, form action, frame, img src, css href, javascript source or any line of code that makes a request to a CFML resource. I though things in there that seldom request a CFML resource like the img src, but they sometimes do. And if they do, they need the token.

As to users sharing links, they seldom understand the relationship between the links and tokens and their sessions. So just be clear and careful with your urers so that when and if they come forward with this sharing problem, you can point to where you explained how and why that would happen.

I try to never underestimate the troubles users can cause me.

Using Session Variables for User Login - sometimes they don't persist... what am I doing wrong?

1 Correct answer