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.
Related
I can't seem to find a definitive answer on the internet, so I'm asking here.
When one uses session_start(); in a .php script and saves some values, when does the session end? So when would those values not be accessible again?
I've found that refreshing the page or stopping the session code-wise would stop it, and a possible time-out would stop the session as well. But what about navigating away from the site and returning a minute later? And closing the browser?
As for the last one, on mobile, what does 'closing the browser' mean? Closing the tab or even minimalising the site?
If your session values are not linked to any cookie, the session will end when the windows browser will be closed.
If your session variable comes from a cookie, the session will end after time specified in the cookie file.
In PHP, sessions work with a cookie of type session. Server-side, the session information is constantly deleted.
To set the lifetime of a cookie in php, you can use the function session_set_cookie_params, before the session_start:
session_set_cookie_params(3600,"/");
session_start();
For ex, 3600 seconds is a one hour, for 2 hours 3600*2 = 7200.
But it's a session cookie, the browser can make it expire by himself, if you want to save longer sessions (like remember login), you need save the data in the server and a standard cookie on the client side.
Navigating away from a site when using cookies will not break the session.
There are two things that can effectively end a session:
The cookie linking it to the browser gets destroyed. PHP typically uses session cookies. These are deleted when the browser is closed. The browser, not the tab. They can also be deleted manually.
When the server hasn't received a request from the browser with the session cookie for the session for a certain amount of time (defined in session.gc_maxlifetime) and it cleans up the session data.
I have a weird problem. I have a web page, that on the main page sets a session variable for each user that visits, and then on the next pages if the session variable is set, some stuff is shown, and some other isn't. The variable i'm setting is just an "1".
$_SESSION['user_id'] = $user_id;
Everything is simple, everything is working great, but I have this one user, that the server doesn't save the session variable for. Just one guy as far as I know. What can be causing this behaviour? He is using a mac if that matters, but on other macs the website works great.
Thanks.
When you call session_start() PHP sets a cookie with just the PHPSESSID variable set. This variable is used to identify the client browser with the session data on the server. If your user has disabled cookies, then it is not possible to use sessions without passing PHPSESSID back and forth in every request via GET or POST.
HTTP is a stateless protocol. IF session would be only in server side, how could it be able to distinguish between users?
[HTTP is a stateless protocol means: HTTP requests are responded from the server, and it forgets who sent the request, where did that come from.]
This is why cookies are storing the session ids.
In other words, if a user is disabling the cookies, he is not allowing PHP to set the session for himself. This is the reason behind.
I'm using a PHP session for a website to display a disclaimer page when the user first logs on to the site. After the user's browsing session, or when they close their browser, the session should be destroyed automatically. It is working properly in all browsers except for Chrome. After some research, I found this which led to this. If it is indeed a bug with Chrome, how can I work around it?
Session cookies are suppose to be deleted if browser being closed and they are sent without expire time.
You can define session_cache_expire before start session first time:
session_cache_expire(60); // expires after 60 mins
And then do session_start();...
Instead of relying on the browser to cancel the cookie, set it to expire fairly quickly, and keep the session "alive" by renewing the cookie on subsequent page requests.
<?php
session_set_cookie( 60*15 );
session_start();
This example sets the cookie to expire after 15 minutes (you might set a different expiry, depending on how often you expect your users to send page requests: or, you could set it for only a minute or two, and get a fresh cookie via XHR just a little more frequently than that). This won't make Chrome delete the cookie, but you at least know it won't be floating around indefinitely.
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.
I know how to create a cookie that will expire after a certain amount of time, and I know how to create a cookie that will expire when the browser closes.
However, I can't seem to find a way to create a cookie capable of doing both. Is it even possible? Would I have to create one of each type of cookie and check for the existence of both before considering either to be valid?
Create a cookie which expires when the browser closes. In the PHP session, mark when you issued the cookie. If the cookie is presented to the server (meaning the browser never closed after issuance) check the issuance date (what you earlier stored in PHP session) against the amount of time you wish the cookie to be valid (TTL). If the cookie was issued too long ago, consider it invalid and send the command to delete it.