session immediately timing out for some users

[Guest]

I am having a session issue with a handful of users, and I am pretty sure it is not cookie related. They can login to my site with no problem (which sets a session variable to indicate they are logged in). However, as soon as they try to go anywhere in the site, their session seems to have expired, and they are taken back to the login page. They all have their browsers set to accept cookies. I even had one helpful user installed FireFox (most current version), and she still has the same problem. I also create 3 test pages to try and see what is going on.

1st test page
Creates a cookie and a session variable using the following:
<CFCOOKIE name="test" value="1">
<CFSET session.test = true>
then, on the same page, it does an IsDefined for the fresh cookie and session variable.
Result on user's browser: both are defined.

2nd test page (which she links to from the first test page):
simply does an IsDefined on the test cookie and test session (created on the first page).
Result on user's browser: cookie IS defined, session IS NOT

3rd test page:
simply expires the cookie and clears the session variables (<cfset StructClear(Session)>) in case we want to retest.

So, I don't think this is a cookie issue. She has even added my site (in IE7) to her "Trusted" sites list.

Thoughts?

BTW, I am running MX6.1, with plans to update to MX7 in the next few weeks.

[Guest]

> then, on the same page, it does an IsDefined for the fresh cookie and session variable.
> Result on user's browser: both are defined.

The cookie is not set on the client until the page finishes. So how are you testing that the cookie is on the client from the page that <CFCOOKIE> is on?

[Guest]

Thanks for the reply, jdeline. That's why I created the second page. Once the user goes to the first page, where the cookie is set, she then clicked on the link to take her to the second page. That second page looks to see if the cookie is still there by doing an IsDefined("cookie.test"). I also do an IsDefined("session.test") (which was also set on the first page). And, of course, my results of the second page (mentioned above) are that the cookie is found on the second page, and the session is not.

[Guest]

What does your <CFAPPLICATION> tag look like in Application.cfm? And what is your server platform?

[Guest]

<CFAPPLICATION NAME="mywp"
SESSIONMANAGEMENT="yes">

And I am running IIS6 on a Windows 2003 SP1. Keep in mind, I only have this problem for a dozen of so users, of several thousand.

[insuractive]

You can also check for the cookie client-side by having your users enter:

javascript:alert(cookie)

in the browser location bar. I've found that helpful in the past.

[Guest]

Ok....I have a little more info that I am hoping with spark an idea with someone. Seems the domain name has something to do with it. If I have the user access the site via a slightly different domain name, everything works just fine. So, for example:

test.mydomain.com - session timeout problem occurs
www.mydomain.com/test - session timeout works perfectly

Both point to the same physical directory.

Any ideas?

[Newsgroup_User]

test.mydomain.com - session timeout problem occurs
www.mydomain.com/test - session timeout works perfectly


I'm not an expert on cookies but it is my understanding that they are
'domain' specific and will not work in the above situation unless the
optional "domain" level is used.

Have you tried having these uses clear their cookies to make sure it is
not an issue of a valid but outdated cookie causing problems?

[Guest]

I like the idea of having the user clear his/her cookies (or at least the one(s) related to the domain that is not working correctly). However, unless FireFox and IE share cookies, I don't see why *both* would have the session timeout issue. I actually had one user install FireFox after she started having problems with session timeouts in IE. Does FireFox give installers the option to copy cookies from IE (along with favorites, settings, etc.)? Maybe she had a bad cookie in IE, and it was copied over to FireFox? Seems like browsers sharing/copying cookies would be some kind of security issue.

Nonetheless, I'll see if I can get the user to kill off any cookies related to my site.

[Newsgroup_User]

Are you doing this domain switching? For example does a user og to
www.mydomain.com the cookie get set then they follow a link to
test.mydomain.com?

I have a vague recall that there are security options in modern browsers
and some third party security add ons that prevent different domains
(i.e. www and test) from sharing cookies.

Also, any similarity with these users possibily being behind some kind
of firewall/proxy servers. Back in the day, around the turn of the
century, some firewall/proxy servers where not very friendly with
handling cookies they would cache them and share them in strange ways.
So if some ancient hardware could be involved.

Finally there are some draconian "security" tools that do remove cookies.

That's all I can think of for now.

FunTommy wrote:
> Ok....I have a little more info that I am hoping with spark an idea with
> someone. Seems the domain name has something to do with it. If I have the
> user access the site via a slightly different domain name, everything works
> just fine. So, for example:
>
> test.mydomain.com - session timeout problem occurs
> www.mydomain.com/test - session timeout works perfectly
>
> Both point to the same physical directory.
>
> Any ideas?
>

[Guest]

Thanks for your replies, Ian. No, I am not attempting domain switching of any sort. Users normally log into test.mydomain.com (to keep with my example). I just had this one user try log into www.mydomain.com/test to see if this helped.

I'll look into them possibly having the firewall/proxy server or security tools you suggested. My problem is that most of these users are not very tech savvy, and may not know how to find this info. Honestly, I am dreading having to walk them through finding a particular cookie and deleting it.

Thanks, again.

[WebPexDev]

Not much help but I'm having the EXACT same problem on a production server. Of thousands of users a few dozen have intermittent problems. One user in particular it happens to every time they log in. Once they log in, click a link, and get booted because their session expired, they can log in again with no problems. I assume you are using a CFLOCATION tag to direct the user to a page after they logged in. I haven't tried it yet but I added the addtoken parameter to the tag to have it pass the session id with the URL. Other than that, I haven't been able to narrow it down either. I have to assume though that it is some specific client issue.

[Guest]

Thanks WebPexDev. You are correct in that I use CFLOCATION to send the authenticated user on his way. I don't have the addtoken parameter specified, but they are being added automatically (default for MX). Do you think suppressing the tokens (addToken="no") might do the trick?

BTW, I had one user delete his cookies (he willingly deleted all of 'em)...no help. I wonder if my upgrade to MX 7will do anything? That's still a couple weeks out.

[Guest]

Well, it has been 5 months, but this issue has not gone away. In fact, I continue to hear of more of my users encountering this issue, though I wouldn't say the issue is growing at a rate disproportionate with the growth of my user-count.

I have also become aware of several other CF administrators that are encountering the same thing (based on a third-party CF Forum I am following). It would be great if one of the Adobe Support folks monitoring these forums could weigh in. The three test pages I reported on in my very first post pointedly exposes the issue.

[Steve Sommers]

Every time I have encountered this issue it has been related to one of three causes: 1) cookies not enabled on the client browser (by far and away this is the #1 cause), 2) a caching proxy server or firewall between the client and your server, or 3) an older browser with some faulty caching logic of it's own.

[Guest]

What are the chances of some ISPs using a caching proxy server between their customers and the Internet? And if that is the case, can you recommend ways to keep the proxy from messing up the sessions?

It seems logical that the cookie setting is the cause. But if that were the case for my issue, I don't see how my test pages would have yielded the results that they did.

[Steve Sommers]

For me, my company hosts our own servers so I cannot my guess about whether or not ISP's can cause this would be just a guess - but my guess is that a misconfigured firewall on the hosting ISP side could cause this.

On how to actually fix it, I'm not sure. I diagnose the issue for our support department and then they then refer the customer the customer's IT department and it usually gets resolved.

One trick I've found that is not pretty is to append a dynamically generated UUID onto every URL. My application.cfm page containd <cfset REQUEST.UUID=CreateUUID()> and I append this to all the URL's of the pages with this issue. The actual UUID is not used on your side, it is simply to defeat caches.

[Guest]

Thanks Steve. Nearly all of my users encountering this issue are at their home rather than work. Otherwise, I probably would have had them "log a ticket" to get the issue resolved.

The unique ID suggestion is a good thought. But, I do believe CF already appends a CFID and CFTOKEN to the URL that are unique. Of course, they only get appended after the user is authenticated and forwarded (via CFLOCATION) on to the main page. That main page requires there to be a session to even be displayed (which it does)...so we know the session exists at that point. After that, though, the session is gone.

[Newsgroup_User]

The point of appending the unique ID is that it is different for every
single request. The CFID and CFTOKEN are going to be the same for all
the requests from a given user for a given session. By making the URL
different every time a cache system will say this is a different page
then any saved pages it has and thus return a fresh page from your server.

Some personal firewall/anti-spam/anti-popup type software can be
unfriendly to cookies as well. Requiring users to explicitly accept
cookies from any given website otherwise the software blocks the cookies.

[GavinBaumanis]

Well I just thought I would pop in here and let you all know that I am having the exact same problem.

Session variables are simply not being saved correctly.
But strangely some are.
I.e. my login page has a collection of CFSETS for about 10 session variables.
Some manage to be saved correctly, some do not.

it is weird!... but since it is happening on our production servers, for application we host and our users pay for.... it is really becoming an issue for us.

[spotlope]

I wish I had something to add other than "me too", but here goes, anyway. My site uses session variables to indicate a successful login. During development, this worked flawlessly (doesn't it always ;-)), but now that a few hundred users are hitting the site, a handful, maybe 7 ot 8 out of 250 or so, are simply unable to retrieve session variables on any page after the one that sets them. I've worked with each of these customers individually, and so far I haven't seen any common threads. In one case, a user even tried to login both from home and work, using two different versions of IE on XP (home) and Vista (work), and in each case, the session variable wasn't set on the next page he visited after logging in.

I use cflocation to move the user to a different page, always with addtoken=yes. I've even tried disabling cookies on my maching using Firefox and IE 6/7, but in every case the variables still work. To say that this is getting frustrating would be putting it mildly.

[Newsgroup_User]

proxies & firewalls, and other gremlins may be at play here...

---
Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com

[BKBK]

FunTommy wrote:
<CFAPPLICATION NAME="mywp"
SESSIONMANAGEMENT="yes">

Pretty thin, in my opinion. It might be of importance to your case that the default setDomainCookies is false and the default loginStorage is cookie. I would use something like

<cfapplication name="mywp"
applicationtimeout="#createtimespan(1,0,0,0)#"
sessiontimeout="#createtimespan(0,0,20,0)#"
sessionmanagement="yes"
setclientcookies="yes"
setdomaincookies="yes">

[SafariTECH]

Here is something to check - I found this out after trying to debug a similar issue with a .NET app and it may apply here as well. It fixed our .NET app immediately.

Since you host your own servers (OP), there is a possibility this may be occurring.

These instructions apply to IIS but possibly it could be similar for other servers.

On IIS, go to the website and check the properties where it shows you the AppPool it is using.

Now go to the AppPool and check its settings - check to see if your AppPool is set to use more than one worker thread. If it is, that is your problem - set it to 1 worker thread and the problem will most likely disappear.

if you need this AppPool to run more than one worker thread, then make a new AppPool with the settings you need for CF (i.e. single worker thread) and then assign that AppPool to the CF website(s).

If that doesn't help you, then I would still be looking into proxies, caching, and cookie issues.

[Steve Sommers]

Glen,

Is there a Microsoft knowledge base article or white paper that you referenced for this solution? My initial thought is that you fixed a broken leg by amputating the entire leg.

If the problem is related to worker threads, one thing we found in the early days of using CF5 was that CF seemed to work best if the worker thread setting in IIS matched the thread setting in the CF administrator. For us we use 10 for both settings. Now I don't believe our thread matching voodoo had anything to do with the topic of this thread, but who knows?..