I have been working on a login system in php. The thing works pretty well but I have 1 funny Behavior I cant get rid of. Basically if I perform many quick refreshes (hitting f5 like crazy) I get logged out.
This is because the system relies on the server refreshing a cookie in the browser every time a request is issued. I have the feeling that when refreshing very quickly, the request N+1 is issued before the cookie returned by the request N has been saved in the browser. This leads to a misalignment of the info in the provided cookie and the info expected by the server.
In fact if I hit f5 regularly, say once a second, the authenticated state is maintained and everything works fine.
Any1 has ever had a similar problem? As far as u know, is the process saving cookies executed in a different thread in the browser? That would explain my problem I guess.
gracias hombres
It's probably not a problem of saving the cookie, but a problem of aborting the request.
browser sends request to server
server handles request, prepares new cookie, invalidates old cookie
you hit F5
browser aborts request, issues new request with old cookie
server sends response including new coo--
server receives new request with old, invalid cookie
And yeah, that happens. To avoid this causing problems you might want to allow the last two cookies to be reused, but that requires some manual session juggling.
Related
For reasons out of my control I need to send form data to an other server and return back right away after it has been processed and alter the state of an entry in my local data base when returning.
In principle it works fine but when I return it seems my session has been terminated and I need to login again in order to reach the page I want to reach. Unfortunately, this hinders my script to actually inform my data base that the external data base has processed the data. Of course I could open up the page for public access but I want to avoid that. An other option would be to send a key with the form data and to only bypass the need for a login if the returned key is correct.
But is there a way of telling my session to only terminate after a certain time instead of when leaving the page? (Of course I want to keep the possibility to deliberately terminate the session on logout.)
I just realised that the problem seems to occur on Firefox on Windows and on Mac but not on my GNU/Linux system. There I stay logged in when leaving and returning to the web page. This is the reason why at first I didn't know that people could have this problem.
I found out that also creating a session on the external page ended the original session (at least in Firefox on Windows and on OSX). After removing the session_start() on the external page the session stays alive as intended.
It seems there can be only one active session in any given tab and creating a new session terminates the old one. (However, this termination only happens on Windows and OSX but not on Firefox ESR GNU/Linux.)
It is strange that the default setting for session cookies is to be deleted if a new session is started (if not on Firefox ESR on GNU/Linux).
What ever the true explanation is: this is the behaviour I discovered.
I'm having a problem with session cookies that i've not seen (or maybe just not noticed) before.
After a certain amount of time (not sure how long) the session cookie starts returning null to my browser (using Chrome). I can see the cookie on my browser and on the server but it is not updatable.
If it gets to the end of its lifetime, should the server reissue a new one automatically if the browser sends a cookie request that's no longer available?
If not, what's the accepted process to get rid of the expired session cookie and issue a new one?
This is a new server that i've never used before so I don't know if it's just set up differently or i've just never noticed this behaviour before.
I have the following situation:
User makes request to PAGE A that displays a form (server stores cache of this page)
User submits the form to CONTROLLER that is used for form submit
CONTROLLER finds an error in user submitted data, sets a cookie ERRORS detailing such, and redirects the user back to PAGE A
PAGE A shows the original content plus the ERRORS (server stores cache of this page)
PAGE A deletes ERRORS cookie
This works, but only if I don't use cache on my system for PAGE A.
Problem is that, after deleting the cookie, browser makes a request to my server without the cookie and gets a 304 Not Modified error and, as a result, the browser still shows the page with the error, instead of without (from the original request). Server stores cache properly (for page that has an error as well as an error-free page).
Basically the server has two cached pages now: PAGE A and PAGE A WITH ERRORS.
Browser, whose last known page was PAGE A WITH ERRORS asks for server a page with conditions of PAGE A, instead of PAGE A WITH ERRORS, since cookie does not exist anymore. But it thinks that the 304 response is about the PAGE A WITH ERRORS, instead of PAGE A. I even checked the data sent by the browser, it knows that it got PAGE A WITH ERRORS with the ERRORS cookie, yet accepts 304 not modified when making requests without that cookie. It does not validate its own cache against the conditions it was created under.
Doesn't browser validate its cache with the cookies it has set?
And is there a workaround for it without setting some GET variables for each request? Another alternative is to tell servers to never cache pages that have such an ERRORS state set, but that would be a hack.
Apparently the solution was to include this as a response header:
Vary: Cookie
This will take cookies into account in caching engines.
EDIT:
There is a problem though: Chrome, Internet Explorer and Firefox work as expected, but Safari and Opera both ignore 'Vary' header when storing and validating cache.
client-side sessions (a.k.a cookies) are probably not sufficient for this scenario...
would suggest server-side sessions instead. Even if Vary headers might work - with $_SESSION you'll be on the save side.
Cache-control: public is probably not what you want. Public essentially says that you're working with static, globally accessible data. It doesn't change per user. It's caching globally because you're claiming that the data is global.
As soon as you start changing per user, caches are having their assumptions violated. 'private' is more akin to what you want.
That will mean that you get less of the good middle-man caching, however. You might be able to hit some middle ground with re-validation, or with appropriate use of Vary headers.
I'm keeping track of the time that users are logged in. After they close the whole browser they are logged out; but when they only close the tab (there's only one tab), and navigate back to the website within a few minutes they are logged in again.
Someone told me that this behavior can be changed in the server configuration. Does anyone know how?
I'm using PHP 5.2 and Apache. Just a normal webserver. I'm also using the Kohana 3 PHP framework. For logging users in there's being a session set with a cookie, in the cookie there's a session id.
Thanks!
You cannot reliably find out when the user closes your page - unload-related events also trigger when navigating to another subpage on your side.
So the most common solution is to simply make a session time out after x minutes of inactivity.
Additionally, if you set your session (id) cookies without an expiry time ("session cookies") they will be deleted when the browser is closed.
By the way, a not really good "solution" for your request would be setting the session expiry time to a very very low value (30 seconds) maybe and "refresh" the session through an AJAX request in the background every ~15-20 seconds. However, if someone's connection is very slow the request might arrive too late and besides that, this solution would cause lots of unnecessary traffic.
I'm writing a proxy script that ideally does the following things:
Proxy waits for request for certain protected pages from end user
Posts login information to page. The login information is hidden to the end user.
Proxy reads the 'set-cookie' response from the server and 'hands off' this cookie to the end user. At this point the end user is finished interacting with the proxy.
I've decided to take this approach because I found it very difficult to proxify certain types of pages (like those with lots of javascript code). I thought that this logical flow would be sufficient because my only requirement is to hide the login information from the end-user and my manager says that handing off the cookie is fine.
My problem is that I cannot think of how to 'hand off' the cookie to the end user. First, the cookie is generated for my proxy server, not the user. Does this matter? It seems that I get all the set-cookie responses, but when I make another request those cookies disappear.
Can anyone point me in the right direction, or point out any inconsistencies in my thinking?
Thanks!
Most likely your problem is with cookie scope - if it's not defined, the cookies you hand off back to the user from your proxy are valid only for your proxy URL and are never submitted when the user is redirected to the original site.
It is also possible that the server on the other end tracks not only the cookie presence but the source IP as well.