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
Related
Lets say session for an application is opened and its session expiry time is 15 min.
Scenarios:
Leaving the application for 15 min and doing some action after that - leading to Login Page.
In other way I am removing the Browser cookies by using (Ctrl+Shift+Del) and trying to navigate in the application - leading to Login Page.
The Question is: Will both of the above cases were one and the same or will there be any difference in the behavior.
The first scenario is based on a cookie expiring while the second one will have the cookie removed.
If you are guaranteed the refresh for the first case is made after the cookie expired, then the client behaviour will be the same (login page) although the internal workings will be different (check the cookie exists vs check its expiry date)
If you can't guarantee the operation will happen after the cookie expiry, then you won't get the same outcome.
Depending on what you do on the server, you might end up with multiple sessions for the same user in the second case, because the server doesn't know the user has deleted the cookie (there are mechanisms to compensate for this though).
According to Where are $_SESSION variables stored?: "Usually the session-id is stored in a cookie, but it can also be appended to urls". Once I read that, I asked myseld: so, why is it said that the session-id is deleted when closing the browsers window if it is stored in a cookie?
Then, after Googling a little bit more about it, I found that there are two different types of cookies: session cookies and persistent cookies.
I guess that the session-id is stored in a session cookie, but: beyond the name evidence, why is a session stored in a session cookie and not in a persistent cookie? What is the need of creating a new session-id every time the browser is opened? Why don't re-use it?
There are many reasons you store sessions in session cookies. One case is public computers: if the previous user has logged into their bank account at the library to pay bills you don't want the next user to be able to log into that session by just looking at the History log in the browser. Being sure that the session is gone by closing the browser alleviates this.
You can also use persistent cookies, and many do too, such as Gmail, but what is then important is to set an expiration time that is not too long. Otherwise, if someone gets hold of the session id they can use that forever. Usually the server will send you a new valid session id some minutes before the next goes out to keep your session alive.
For example, if a user just closes the browser window without logging out (the PHP script unsetting and destroying the session and expiring the session cookie), by default the cookie used to store the session ID will have expired the next time the user opens the browser so s/he won't have access to the same session.
But what happens with the file on the server side that was used to save the session data and what happens with the session data itself?
Will it still be available?
There are parameters called session.gc_divisor and session.gc_probability that you can configure in php.ini or in the .htaccess.
These parameters give the probability (gc_probabiltiy/gc_divisor) to execute the garbage collection of the sessions at every request.
The garbage collection is a process whick check if the last modification of the session file is older than session.gc_maxlifetime and remove it if it is !
So yes, the data are still available for a while on your server.
How can I increase the security of my sessions?
$this->session->userdata('userid')
I've been throwing this little bad boy around for my ajax calls. Some cases I haven't. Then I was like, is this really secure using id from the DOM? what if the DOM is changed to hack user accounts data? So then I was like I guess anytime a user is doing something relating to their id, only sessions should be referenced. Am I right?
Referenced like so:
$this->some_model->do_data_stuff($dataId, $this->session->userdata('userid'));
Then I read this:
While the session data array stored in the user's cookie contains a
Session ID, unless you store session data in a database there is no
way to validate it. For some applications that require little or no
security, session ID validation may not be needed, but if your
application requires security, validation is mandatory. Otherwise, an
old session could be restored by a user modifying their cookies.
http://codeigniter.com/user_guide/libraries/sessions.html
I'm not going to be storing financial data but I don't want any data on my site corrupted ever. Does SO use session validation? How much overhead will this validation cost? How would a session be hacked? What are some things to look out for with session security?
Using CodeIgniter sessions with database is going to be fairly secure. You just don't have to trust the input that the user gives. Even if you are using AJAX, the CodeIgniter session will work just like any standard call, so the same security goes on.
What happens with the CodeIgniter session is that the server stores the cookie, and every time the user does an action that would change the content of the cookie, it is first compared to the previous cookie.
If the user changes the content of the session cookie in the browser, CodeIgniter will notice on the next server call, and create a new session for the user, basically logging him out.
CodeIgniter doesn't really need the data stored in the cookie in the user's browser, and as long as you're using
$this->session->userdata('userid');
you're going to get trusted server-side data. The user can't change that. Furthermore, the cookie can be encrypted, and you should have it encrypted. Just look in config.php of CodeIgniter.
There are several other protections around the session data: the short refresh timeout (usually 300 seconds), it checks if the IP changed, and if the browser changed. In other words, in the worst case scenario, the only way to spoof the session data is by having the same version of the browser, having the same IP, getting direct access to the computer to copy/paste the cookie, and getting this done within 5 minutes.
So, watch out for the guy sitting beside you!
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!