I'm wondering how long php sessions are stored in server memory.What if user logs in (sets session variables in server) and he keeps his browser open for a long time suppose 30 days and he reloads the page on the 31st day? Can browser access session variables(browser still has session cookie)?
Default php.ini sets the session expiration time to 30 minutes.
Check out these settings: session.gc_maxlifetime and session.cookie_lifetime
As long as the browser have the cookie stored, it doesn't matter if it is closed or is open.
If you want to store the session for lets say 30 days, you can add:
ini_set('session.gc_maxlifetime', 30*24*60*60);
ini_set('session.cookie_lifetime', 30*24*60*60);
Normally you would code as part of your session handling code a function for expiring sessions after some time has elapsed, so in that case it would't matter how long they left there browser open
I think this depends on what you have set in php.ini http://php.net/manual/en/function.session-set-cookie-params.php
Related
I have an issue with session , my session is automatically destroyed after few minutes of inactivity ,i think its must be 24 minutes i.e. 1440 seconds.I want to session remain for a long time , i am using .user.ini file on the server and set session.gc_maxlifetime to 31557600 seconds and session.cookie_lifetime to 31557600 but nothing happened for me .Its still logout after 1440 seconds of inactivity .I have also attached session value of png image of phpinfo.
I hope your answer or any help will work for me.Thanks.
I'm not sure why your settings aren't working but I use the following on my scripts to overwrite the php.ini settings for session maxlifetime and session_save_path:
session_save_path('/pathto/writable/dir/on/your/account');
ini_set('session.gc_maxlifetime', 24*60*60); // 24 hours; change as necessary
session_start();
NOTE:
The session_save_path is important because the default path is /tmp and it may get deleted by the system administrator on a daily/week? basis.
In my experience, it's always been related to the php.ini file. In your case, the master and local values for session.gc_maxlifetime contradict. (gc stands for garbage collect) They don't have to agree with each other, since the local value is used for the running script. It just means there's two php.ini files on your system, located in different places, and the local php.ini file is overriding the master php.ini file settings. But, I'd be VERY suspicious of any files on your server which call session_start() which use the master php.ini file, or call ini_set(...) within the script itself. The way this works is that no matter what the value is set to, it only has meaning when it's time to do garbage collecting. And garbage collecting is done by session_start() but you can also trigger garbage collecting in other ways such as SessionHandler::gc or a cronjob as explained later in this post. When called, it checks the last modified time of the file on the server storing your session information. If the number of seconds that elapsed since then is greater than the current session.gc_maxlifetime value, it will destroy the session. Note this is the last modified time, not the last accessed time, so you'll want to change your session data frequently to prevent it from getting deleted if it's not changing. You should also be aware that there is a setting here, called session.lazy_write which, if enabled, and is enabled by default, WILL NOT update the last modified time of the session file in the event which the session data did not change. Thus you'll want to disable this if you want to minimize the chances of sessions being destroyed early for some unknown reason, or store a timestamp on the session so the data is always changing and you know when the session was last used, if old, you can manually call session_destroy(). To start another session, you can commit with session_write_close() then recall session_start(). Or, do all 3 at once with session_regenerate_id(true).
Nextly, if you initialize a session with session_start() with your intended settings, and continue to call session_start() with the intended settings with each request, awesome. But, once any file on your server calls session_start() with a different value for session.gc_maxlifetime, either from using the master php.ini value in your case, or the script calling ini_set(...) and ignoring the master value, it will check the file's last modified time against a different value and destroy your session despite your intended settings - is assuming it gets elected to be one of the 1 in 100 requests which have to garbage collect.
Another thing to be concerned with is session.cookie_lifetime. A value of 0 here turns the cookie into a browser session cookie. This means if the user closes their browser, then the session cookie will be deleted by the browser. Your master value is using 0. But your local value is using 31557600 (the average seconds in a year). So you should be fine here. But keep your eyes open if any scripts on your server override this value, use a value of 0, or use the master php.ini file.
You should also be aware of the default 1% garbage collecting CHANCE that a session will be destroyed as defined by session.gc_probability and session.gc_divisor which default to 1 and 100 respectively. Garbage collecting is done when start_session() is called, if, and only if, the request "randomly" gets picked to be the request to manage the Garbage Collecting. This means that even if the number of defined seconds for a session elapsed for it to expire, start_session() STILL won't garbage collect even for this expired session. Rather, most users will notice their sessions expire exactly to schedule due to the cookie the browser keeps track of having its timestamp expire. But the session isn't enforced until PHP garbage collects as per the garbage collection change when start_session() is called. If you want sessions to be wiped clean when they've expired, and start a new one, you should use session_regenerate_id(true). The true here means trash the $_SESSION data tied to the previous session and toss them a different session id as though their session expired.
You should also be aware that some systems, such as debian-based systems, have a cronjob which runs every 30 minutes to garbage collect based on the master php.ini configuration information.
See the comment here by Christopher Kramer: http://php.net/manual/en/session.configuration.php
I cannot verify if the above information about debian systems is true, but I've considered garbage collecting with a cronjob before to speed up users' requests so no one user gets stuck having to wait for their request to go through due to the maintenance which a cronjob could be handling.
In terms of solutions here:
One solution here is to adjust the master php.ini value, if you have access to it, then search your server for any PHP files which might be calling ini_set to see if there's any files conflicting with your settings to make sure they're not causing the unexpected behavior.
Another solution would be to limit such conflicts the script might be encountering by: (1.) renaming the session.name to something other than PHPSESSID. And/or (2.) changing the session.save_path path. Either of these by itself would suffice and avoid script conflicts.
A temporary fix might be to do something like change your session.gc_probability to 0 so the session garbage collecting NEVER happens. Or make it a much smaller chance by using something like session.gc_probability=1 and session.gc_divisor=100000. Then setup a cronjob to call SessionHandler::gc
See http://php.net/manual/en/session.configuration.php for more session config information.
Lastly I'd like to point you to this post which suggests good practices to prevent session hijacking, and for the most-part is the post I referenced when putting this post together: https://stackoverflow.com/a/1270960/466314
Note that it uses an approach to sessions which makes sure sessions expire on time, and not later (although browsers do a good job of this already with cookie garbage collecting). And it also makes changes to sessions, keeping track of the session last used time, so the session data is always changing to avoid the issue with session.lazy_write.
This concludes my suggestions. If you can narrow down the issue, try searching stackoverflow or asking a new question.
As stated here :
The best solution is to implement a session timeout of your own. Use a
simple time stamp that denotes the time of the last activity (i.e.
request) and update it with every request:
if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1800)) {
// last request was more than 30 minutes ago
session_unset(); // unset $_SESSION variable for the run-time
session_destroy(); // destroy session data in storage
}
$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp
Updating the session data with every request also changes the session
file's modification date so that the session is not removed by the
garbage collector prematurely.
I have heard many times that a session get destroy as our browser close.
Then how I keep logged in after closing and reopening my browser.
Please help
You keep login because your sessions are not destroyed even when the browser is closed. Sessions destroying on the closing of the browser is default behaviour but but this does not mean its the only behaviour. You can extend the expiry time of session.
This behaviour can be changed in the php.ini file by altering the line:
Keeping a session alive indefinitely
session.cookie_lifetime = 0
So just check when you have set the expiry time for the sessions. Although using cookies will be a good option
Note:- Remember to restart your web server after making this change.
You have to use Cookies.
You can use the setcookie() function and read the value with the $_COOKIE['cookiename'] variable.
Use cookies, with a predefined expire time, I like 1 year
You can use cookies. Cookies are data that is stored directly on the HDD so that even if the browser was closed, cookies still can be read if it haven't expired yet.
Here is an example of setting up a cookie.
Paste this code BEFORE the tag.
<?php setcookie("$name", "$value", $time); ?>
Where $name is the cookie name, $value is the cookie value and $time is the time when your cookie will be expired. For example $time = time()+86400; will set your cookie to expire after 1 day. The 86400 value is the number of seconds in a day, 60seconds times 60minutes times 24hours, so 60x60x24 = 86400.
Basically, a php session won't expire while a user is surfing on a website. But "while the user is surfing on the website" means that there are get and post requests. Nevertheless, i can't figure out if there has to be new requests, or if one active request is enough to maintain the session…
For instantce, i have a big file upload by post. It could then take hours. Will the session expire or not ?
The lifetime of a session depends on the ini setting session.gc-maxlifetime. Every access to the session (read and write) resets the timer. After the timeout, when the session garbage collector runs, the session values are destroyed.
The default value is 1440, which means 24 minutes. So if you have hits that access the session in any way at least every 24 minutes, the session values will stay.
If you need the session to stay alive longer than that, you can extend the timeout with ini_set (use before session_start()), for example:
ini_set('session.gc_maxlifetime', 24*60*60); // 24 hours
It shouldn't. Usually when I work with $_SESSION's, they last for a day or so. But it might on some servers. In that case you need to add cookies, too. With cookies you can exactly manipulate the time the person can be online for.
I'm logging my admin like this:
session_start();
$_SESSION['admin'] = TRUE;
When I login and stay inactive for like 10 minutes, then refresh, the session is dead and the admin is logged out.
What do I need to set either in htaccess or in the php file itself so that the session stays alive for at least 8 hours?
Create a file and put <?php phpinfo() ?> in it and check the output.
The value you want to look at is session.cookie_lifetime and session.gc_lifetime.
gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor).
In your script that is responsible for starting the sessions, you can put
ini_set('session.gc_maxlifetime', 3600); // set session data life to 1 hour
or any other time that is suitable for your application.
In fact, you don't want to want the session don't die.
It's against session nature. A session is something what ends by definition.
Lasting admin session for the 8 hours makes no sense.
If you want to auto-renew it - use a cookie. But don't touch session mechanism itself.
My first question in stackoverflow. Thanks in advance!
I am so confused about the PHP session mechanism. I have understand the session.gc_maxlifetime by PHP - ini_set('session.gc_maxlifetime', 5) - Why it doesn't end the session?. But I still don't know the difference between session.gc_maxlifetime and session.cookie_lifetime.
Question:
What will happened if the time of session.cookie_lifetime is out? Will the session cookie be deleted from the client computer directly?
I need to figure this question, then continue to ask something further.
session.gc_maxlifetime is the time in seconds after which your session data could be considered as garbage data. In other words, you can say that it is the time an unused PHP session will be kept alive.
session.cookie_lifetime is the life time in seconds of session cookies whether the session is alive or not. So the cookies will stay alive until the given time is elapsed
See:
http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime
https://blogs.oracle.com/oswald/entry/php_session_gc_maxlifetime_vs
The cookie lifetime is transmitted to the client. If the cookie has reched its lifetime, the client usually deletes it. So it is client-side. Also the a session can be alive even after the cookie is gone, since you can create the same cookie again, epand its lifetime, or transmit the session-id via the uri.
Hope that helps!