PhilrL9
asked on
ColdFusion Sessions Intermittently Lost in IE
I know many people have had similar issues and I have read countless posts on this issue, yet I cannot find a solution. I apologize in advance if I don't fully explain myself properly, this has been a long, frustrating road.
I have a ColdFusion9 application running on IIS7 with the following settings in applicaiton.cfc:
As you can see, session management is enabled, client management and cookies are disabled. Additionally, I am using J2EE session vars on my server.
In the past I did use client cookies, however, since I believe IE 8, customers started complaining about loosing sessions. So, after much reading and testing, I disabled client cookies and wrapped all of my href and form tags in URLSessionFormat and set addToken in my cflocations to YES.
I still have random users with IE that cannot maintain a session; instead getting bumped back to a login screen with each request.
As I am receiving these complaints third-party via my client, I am very limited in attempting to debug a client's setup. But, one thing I can confirm is that the client does not see the session appended to their URL string. This leads me to believe that URLSessionFormat is assuming that the user's browser will stability accept cookies.
One additional note, the entire application is running on one HTTPS domain: xxx.domain.com. I have read about similar experiences where users had links with multiple hosts: ie, xxx.domain.com and domain.com. This is not the case here.
Again, forgive me if I have not provided enough information!
I have a ColdFusion9 application running on IIS7 with the following settings in applicaiton.cfc:
<cfset this.name = "xxx">
<cfset this.sessionManagement = true>
<cfset this.applicationTimeout = createTimeSpan(1,0,0,0)>
<cfset this.sessionTimeout = createTimeSpan(0,4,0,0)>
<cfset this.setClientCookies = false>
<cfset this.setDomainCookies = false>
<cfset this.clientManagement = false>
<cfset this.scriptProtect = true>As you can see, session management is enabled, client management and cookies are disabled. Additionally, I am using J2EE session vars on my server.
In the past I did use client cookies, however, since I believe IE 8, customers started complaining about loosing sessions. So, after much reading and testing, I disabled client cookies and wrapped all of my href and form tags in URLSessionFormat and set addToken in my cflocations to YES.
I still have random users with IE that cannot maintain a session; instead getting bumped back to a login screen with each request.
As I am receiving these complaints third-party via my client, I am very limited in attempting to debug a client's setup. But, one thing I can confirm is that the client does not see the session appended to their URL string. This leads me to believe that URLSessionFormat is assuming that the user's browser will stability accept cookies.
One additional note, the entire application is running on one HTTPS domain: xxx.domain.com. I have read about similar experiences where users had links with multiple hosts: ie, xxx.domain.com and domain.com. This is not the case here.
Again, forgive me if I have not provided enough information!
ASKER
Thanks and I agree with you. The current scenario is a product of my assuming that there were issues with cookie acceptance. I think the fact that URLSessionFormat isn't presenting the session in the URL string for IE clients that are having issues demonstrates that their browsers do indeed accept cookies.
My issue is what is causing IE to lose that cookie immediately after it's set?
My issue is what is causing IE to lose that cookie immediately after it's set?
> demonstrates that their browsers do indeed accept cookies.
True. And all browsers accept cookies, very few people have them turned off.
But since you have setClientCookies set to false, you are not covered in the majority situation where the client does indeed accept cookies... right?
True. And all browsers accept cookies, very few people have them turned off.
But since you have setClientCookies set to false, you are not covered in the majority situation where the client does indeed accept cookies... right?
ASKER
Agreed again...I am rolling back my changes as we speak and turning client cookies back on. However, this still doesn't affect those few IE users with the dropping sessions - the crux of my issue.
> However, this still doesn't affect those few IE users with the dropping sessions - the crux of my issue.
Do you know under what scenario these clients were losing their sessions? That is, were clientCookies on or off, were they getting their sessions on the URL or not?
I know that I was complaining to Experts-Exchange that my session was getting dropped immediately after login, they said I was the only one so the problem must have been with me. I disabled all my add-ons, nothing really worked (although that is a good idea to try). Eventually the problem stopped happening, I don't know if it was an IE update or EE finally found the issue ! (isn't that helpful?)
... I guess the short story is to look at add-ons..
Do you know under what scenario these clients were losing their sessions? That is, were clientCookies on or off, were they getting their sessions on the URL or not?
I know that I was complaining to Experts-Exchange that my session was getting dropped immediately after login, they said I was the only one so the problem must have been with me. I disabled all my add-ons, nothing really worked (although that is a good idea to try). Eventually the problem stopped happening, I don't know if it was an IE update or EE finally found the issue ! (isn't that helpful?)
... I guess the short story is to look at add-ons..
ASKER
Well again, I have limited access to the end-users' environments. But, it happens both with client cookies on and off and it happens immediately after login also.
> I have limited access to the end-users' environments
Right, and this is where the problem gets really complicated, if you don't have it under your control to test, then how do you know when you fixed it?
I'm guessing here, but maybe something like this to try..
1) try to ask if one of the end-users would be willing to work with you to solve the problem; maybe you could get a look at add-ons and at least if you try something, they can tell you if it's working better or not.
2) perhaps when someone gets the login screen (which I assume happens when they lose their session? or do they get an error?) you can email yourself some information about their session (cgi variabels, session variables, cookies). The challenge is knowing what criteria to test to try and hone in on these end-users.
Try setting your cookies to domain cookies in your application file...
<cfset this.setdomaincookies = true>
Other ideas... since it's unclear whether cookies are being lost or if the sesison on the server is being interupted, you can add your own cookie as a flag.
Place a session cookie that contains an encrypted identifier to the user's Id/session. Whenever a session times out, test to see if the cookie exists, if it does not, you have lost your cookies... otherwise it's the sesison that has gone bad.
Right, and this is where the problem gets really complicated, if you don't have it under your control to test, then how do you know when you fixed it?
I'm guessing here, but maybe something like this to try..
1) try to ask if one of the end-users would be willing to work with you to solve the problem; maybe you could get a look at add-ons and at least if you try something, they can tell you if it's working better or not.
2) perhaps when someone gets the login screen (which I assume happens when they lose their session? or do they get an error?) you can email yourself some information about their session (cgi variabels, session variables, cookies). The challenge is knowing what criteria to test to try and hone in on these end-users.
Try setting your cookies to domain cookies in your application file...
<cfset this.setdomaincookies = true>
Other ideas... since it's unclear whether cookies are being lost or if the sesison on the server is being interupted, you can add your own cookie as a flag.
Place a session cookie that contains an encrypted identifier to the user's Id/session. Whenever a session times out, test to see if the cookie exists, if it does not, you have lost your cookies... otherwise it's the sesison that has gone bad.
ASKER
As luck would have it, some at my client's office began experiencing the issue. I was able to remote into their machine and see it first hand.
I flipped client cookies back on and it instantly started working. As great as that sounds...my configuration is back to where it was when I started getting these complaints! So frustrating!!!
For what it's worth, the client is running 32-Bit XP SP3 with MSIE 8. The only add-ons I see are Windows Messenger, Diagnose Computer Problems and Adobe PDF Link Helper.
I flipped client cookies back on and it instantly started working. As great as that sounds...my configuration is back to where it was when I started getting these complaints! So frustrating!!!
For what it's worth, the client is running 32-Bit XP SP3 with MSIE 8. The only add-ons I see are Windows Messenger, Diagnose Computer Problems and Adobe PDF Link Helper.
I've requested that this question be deleted for the following reason:
The question has either no comments or not enough useful information to be called an "answer".
The question has either no comments or not enough useful information to be called an "answer".
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You definitely do not want to use CFLOCATION with addToken="yes" that is bad news... their session access is available on the URL, if they unknowingly email a link to someone, they will have access to their account.
I would change it to NO asap and then set setClientCookies to true.
Then you can start troubleshooting the issues around this. For example, you can ensure that people have cookie enabled (who doesn't these days?)
You can also maintain backup-session management in the form of a session/browser cookie.
I think it's best if you try to solve the problem with the correct approach rather than the really dangerous one...