In file app/config/session.php I've changed lifetime to 30 days. Using browser console I see that cookie is set correctly.
After an hour session cookie remains unchanged yet my auth session is lost.
I'm using native session driver. It's using the cookie, so as far as I understand session should remain valid till there's a cookie.
Any ideas why is this happening?
There are a few settings in your php.ini file that look like they could be impacting this functionality. I'm guessing the first one is probably the culprit since you are using cookies.
session.cookie_lifetime = 0
session.gc_maxlifetime = 1440
session.cache_expire = 180
Related
I have this problem. There is a site with a codeigniter session time set to 7200 and there are some users logged in.
I suppose some of them will do nothing for over 7200 seconds. If now I change time session to zero (no expiration) the existing logged users will be logged out if they do nothing or not?
Thanks to all.
If you set $config['sess_expiration'] to 0 it means sessions won't expire.
On the next request after you edit the configuration, the session class will look at this setting before cleaning up old sessions, see it is set at "0", and do nothing. All active sessions will remain active, they won't be discarded. There will be no "memory" of the old setting.
In a web app am developing using express.js am having a problem expiring sessions when a user has not been active for more than 10 minutes. Am using connect-couchdb as the session store.
I tried setting the req.session.cookie.maxAge = 600000. But this causes the session to expire 10 mins after logging in irrespective of user activity. My understanding of the documentation is that req.session.touch() will be called automatically by the connect middleware and hence maxAge (and the expires date) should get refreshed so it lasts another 10 mins, but it is not happening!!
I also tried setting maxAge to 600000 on each request and calling req.session.save() but even then there is no effect.
What am I doing wrong?
You are not doing anything wrong---this is a bug in Connect. The session cookie gets updated in the server, but not pushed to the client, and so the client keeps trying to use the old cookie, which will expire sooner than you want.
More details and discussion here.
I have a quick question about php sessions. If I want a session to last for on month (or until a user explicitly logs out) I change the following php.ini settings: session.gc_maxlifetime = 2592000 and session.cookie_lifetime = 2592000 from their defaults of 1440 and 0 respectively. Correct?
Thanks.
session.cookie_lifetime of 0 will keep the cookie till the browser restarts (basically for the entire session).
Setting your session.gc_maxlifetime to such a high value will mean you will have many stale sessions on your server and this might be a issue if you have large numbers of sessions - typically sessions are stored in the system's /tmp folder. When this folder, typically on *nix machines, fills up it could cause problems on the machine - processes start locking up as they fail to create temporary files for whatever reason. (You can change the session.save_path to something other than /tmp so you don't have this issue - especially on shared hosts).
Someone, though, with more experience in server configurations, may know that there are other timeouts like Apache and TCP settings that may trump this value no matter how high you create it.
I believe what you're basically asking is for a Remember Me feature that will allow someone to log in without having to remember their Username/Password and remember the exact state (1 month session).
The Remember Me feature can be implemented with a rotating authentication cookie that is set to the next token in a known series based on the user's login credentials.
The 1 month session feature can be implemented by storing the session's state in a persistent cache (file cache, database, something more elaborate like Toyko Tyrant).
If what you are asking for is a 'Remember Me' the simplest solution is:
Once a user log-in successfully, you create a random hash and store it in a cookie (on user browser) and in the database (joined to the userid)
So when the user call your script first you check the hash, if the hash is present in the databse you automatically login without asking username/password, otherwise you'll ask user/password
In the first option you "bypass" login because the hash identifies the user.
If the user explicitly logout from your site simply delete the session and reset the user hash (on db side)...
Using this method you can also set a timelimit, in cookie simply set the cookie duration, on db side add the timelimit and if a user login using an hash over the timelimit you do not allow the auth login :)
Hope this solve your question
The premise is simple.
New customer arrives at our site, is redirected to the register/login page (since they are a new visitor and no cookie is present) and after registering or logging in (if already have an account but visiting from a different machine/browser) they are taken to the home page.
Every time they subsequently visit, they should not see the register/login page (unless they explicitly log out, cookies are disabled/blocked, or they visit from a different browser/device).
I would think that theoretically, setting the cookie value to an absurdly high number (in our case, 30+ years) and checking for the presence of that cookie before the redirect to the register/login page would work.
In our case it is not. I feel like the session is still lasting roughly an hour or so before a visit back to the home page of the site redirects a user to register/login.
So what am I missing here? Any advice?
---edit---
I had been assured by our web host that session.gc_maxlifetime was not the issue. I set it to 86400 on our development server and after leaving my browser idle overnight, I returned the next day and I think it's working as intended.
One issue I have with this is that it also sets the magento admin timeout to the same value, which may introduce a security risk if an employee is given Magento admin access and then gets fired/quits/etc. I certainly don't want their session to continue for as long as we want customer sessions to last (months).
I'm hoping that the CONFIG>>ADVANCED>>ADMIN>>SECURITY>>SESSION LIFETIME setting is not overridden by this.
Your problem is most likely with the Php session value you need to increase it to match the value in the cookie duration; on your php.ini put the following:
session.gc_maxlifetime = 86400
You need to replace the '86400' value with what equivalent time that you want the session / cookie to last I would advice that you set your sessions and cookie value'604800' that's about a week.
What is going to happen on your server is that magento is going to a session file per session under the var/sessions folder. This can potentially can cause your server to run out of inodes , depends on your server configuration.
Cheers!
I am working on a e-commerce project using the Auth Component for authentication and Sessions Component for storing my cart.
The problem is that the session gets cleared abruptly after a while even when I am actively browsing the site. I know this should be because of the Session timeout but just increasing the timeout value is not the solution I am looking for.
I want the session to expire only when a user closes his browser. Can this be achieved?
AFAIK all you can do is to set a session timeout variable far into the future. Sessions are automatically cleared when the browser is closed (unless you set a Remember Me type cookie). Setting it far into the future will effectively accomplish what you need to do.
How long into your session is it timing out? It should only timeout when your user is inactive for a period of time. If it times out in-between requests, and you know the timeout time has not elapsed, you have some other issues going on. What are the settings in your core.php file regarding your security levels and session timeouts?