Hello,
we have an app running in production that uses auth package for administration part of the website. Everything is running ok in development mode.
But there is an issue in production mode. User is logged out automatically in less than a minute every time after successful login.
All Session config values are default and has not been changed.
Any ideas what could be wrong?
Thanks!
Assuming it's not a code issue, it might be an issue with the cookie configuration.
Can you check what happens with the session cookie that is sent to the browser? Where do you store your sessions? If in the database, is a new session record generated?
I also have the same problem: session values are lost after a variable time.
Since my app has many ajax requests, I thought that this bug may be caused by the session rotation time but it's not.
My session config : http://pastie.org/4739348 (using file driver)
My cookie config is the default one.
In this post: http://fuelphp.com/forums/topics/view/8715, Harro you talked about updated session cookie not coming back with the ajax response, this might causes the problem.
In my case, when session is lost, the session file is not longer updated and no new session file is created.
Does this happen in all browsers?
If it happens regularly/predictably, maybe you could debug it, and see if every response includes the session cookie in the header?
Does your application do concurrent ajax requests?
I only tested in Firefox for the moment.
This happens unpredictably, and my app doesn't have concurrent ajax requests, as far as I know.
I'll keep investigating and get you informed.
I use FF as default browser too, and haven't seen this behaviour.
The session class is built so that if in encounters a collision, if will drop the session update instead of the entire session. So it's a lot more resilient to cookie issues then some other solutions.
Update: I'm 100% sure, it happens only in Firefox (latest), not on Chrome, IE or Safari (on Windows).
To know more about the problem, could you tell me how and when to log sent cookies in the response's header ?
Session updates happen through a shutdown event, and it's the session driver that sets the cookie.
One of the issues I've observed with cookies in combination with redirects, is that some browsers try to optimize the process. When they discover a "Location:" in the header, they stop parsing the header and immediately redirect. If the cookie header is after the location, you lose the cookie..
I haven't observed this with FF though, but I haven't used the cookie driver in a while.
Okay I see, thanks for the explanation.
So, cookies are always sent in the header and :
it appears that FirePHP and/or FireFile, two firebug extensions, are causing the session loss.
I'm not 100 % sure yet, I'll keep investigating
Update: Firefile was the problem...
The problem surfaced again recently, I don't know when, it might be with the new Firebug's version.
In my setup, this problem was caused by the user's agent informations beeing changed when displaying Firebug sometimes.
You can read more about this on : http://codeigniter.com/forums/viewthread/222443/#1032269
Setting 'session.match_ua' to FALSE solved the problem
So it's not related to any specific session driver (problem happened with file and memcached drivers) or to fuelphp generally. There may also issues with IE8: http://codeigniter.com/forums/viewthread/123432/
IMHO, you should add this information in the docs.
I have started to get the same problem here. I use 1.4 and DB session driver and Firefox. I started to get sudden logouts. It's completely random and I can not fix it. Any idea?
No. I use FF as my main browser, and I have not observed this behaviour. DB sessions tend to be very stable. Recently upgraded to 1.4? And if so, did you make sure your timezone settings are ok?
I did not upgrade to 1.4 and I checked my timezone settings and is correct (if we are talking about server side timezon settings?)... And is not only FF problems, it happens in Chrome and IE10 as well. I got a lot of calls from customers lately about this issue.
I tried with 'session.match_ua' to FALSE as suggested by younes0 and I will see how this behaves.
FF and Chrome don't use changing UA's, so I doubt that is going to be a solution.
When you have session issue, the first thing to do is to check times: is the server timezone correct? Is the timezone in php.ini equal to the timezone? Is the server running on time (ntp)? is the timezone in the config/config.php equal to the server timezone? Was a "timezone offset" configured by mistake?
Next step is to check the timezone and time settings on the client. Are they correct too?
You can quickly check if this is there area where the problem is by setting the session expiration to 0 (which means 2 years). If your session now sticks, it's a time/timezone issue.
If disabling the expiration doesn't help, you need to look further. Is the session cookie really sent to the client? What does it contain? Is it send back to the server on the next request?
If you use DB for sessions, and a new session is issued for every request, it should be quickly visible because of the amount of records, all for the same IP/UA.
>>If you use DB for sessions, and a new session is issued for every request, it should be quickly visible because of the amount of records, all for the same IP/UA.
I definitely have this case in one of apps where I see the problem. 12k session records in the sessions table :O!? What can be the cause of this? The timezones settings look to be ok!
Clear all your domain cookies, then request a page, and use something like http-headers or firebug to monitor the request. Did you receive the cookie? That is the expiry timestamp on it. Does your browser report the cookie as stored?
When you click on a link on that page, is the cookie send back to the server?
>>Does your browser report the cookie as stored? YES
>>When you click on a link on that page, is the cookie send back to the server? YES
I have checked the timezone settings again. My Default timezone for app is set to Europe/Ljubljana, but the date.timezone seen in phpinfo() is Europe/Zurich. I don't know if this could cause any issues. There's no time difference between Ljubljana and Zurich. See the image for details: https://dl.dropbox.com/u/1207859/timezone.png
If there's no timezone difference, that is not a problem.
Issue with times and timezones (on both client and server) is that a cookie expiration timestamp is in GMT, so the server will have to convert local time to GMT, and your PC will have to convert it back to local PC time. If something is off, this conversion fails miserably.
Which FuelPHP version is your app on? If not on 1.5.1., I would stongly suggest you upgrade first, to rule out any issues that have been already fixed.
p.s. the cookies in your screenshot do NOT contain the session cookie of your application. So check again to make sure you're looking at the right data. The name of the session cookie is un your session configuration (by default it is fueldid for DB sessions).
>>Which FuelPHP version is your app on? If not on 1.5.1., I would stongly suggest you upgrade first, to rule out any issues that have been already fixed.
I am using git and fetching submodules directly from GitHub. My app is using FuelPhp core: 1.2/master, with Auth and ORM packages both also on 1.2/master.
>>p.s. the cookies in your screenshot do NOT contain the session cookie of your application. So check again to make sure you're looking at the right data. The name of the session cookie is un your session configuration (by default it is fueldid for DB sessions).
Sorry I have cropped the image to much. The session cookies is there: polcenejedbid, expires Thu Jan 29 18:45:58 2015 (I have set expires now to 0 but that didnt solve my problems)
If you're on 1.2, I can't help you any further. That code is old and no longer supported. It could well be that there was a bug that was solved in later versions.
Great I have now updated to 1.5 (core & packages) and now the only thing I get is this: Fatal error: Exception thrown without a stack frame in Unknown on line 0
Donate
