what's the difference beetween if I set second parameter of Auth::attempt() to true and false? If I close the browser and come to page I'm always logged in either if I set true or false. So I can't see any difference. Can someone explain it to me?
From the docs at http://laravel.com/docs/security
If you would like to provide "remember me" functionality in your application, you may pass true as the second argument to the attempt method, which will keep the user authenticated indefinitely (or until they manually logout). Of course, your users table must include the string remember_token column, which will be used to store the "remember me" token.
Laravel by default sets a session cookie upon authentication, with a lifetime configured in app/config/session.php. The default is 120 (minutes) which means your session will stay active for two hours after your last activity. With the remember me set to true, it will set an additional cookie to keep you logged in permanently.
Related
I have a general question about sessions. I am not very seasoned when it comes to this subject. I've tried with:
NewRediStore (gopkg.in/boj/redistore.v1)
NewCookieStore
NewFileSystemStore
I was under the impression that sessions could last between server restarts, hence the need for a 'store'. While my golang backend is running, I am able to set new sessions and retrieve them for multiple users/browsers. No problems there.
When I restart my server, I notice that all session access results in session.IsNew == true.
In Redis, I can see all the session keys after the restart, and even verified that .Getting the session results in the right ID retrieved, but IsNew is still set.
I guess intuitively, this makes sense because there must be some map in memory that leads to the setting of IsNew but I would think that if there was any hit for the cookie key in the store, IsNew should not be set. Am I going crazy? Is there something easy that I am doing wrong? Is this a fundamental misunderstanding of how to use sessions?
Please let me know if I need to include code or additional details.
I would have had the same assumptions you did, and browsing the source, it looks like it should work as you described. You might try debugging and stepping through it, particularly the New method for the store you're using (e.g. FilesystemStore.New or RediStore.New). If that method successfully reads the cookie and finds the session in the store, it should set IsNew = false, according to the source.
Also note that just checking the session ID is not a good way of validating this behavior. If you look at the source, it decodes the session ID from the cookie, then tries to look that up in the backing store. If the lookup fails, then the session ID will match, but IsNew will be true and there won't be any values in the session. Make sure you're setting some value in the session and check for that instead of the session ID. The behavior is different for the CookieStore since it stores the session data in the cookie itself.
I am curious about the value of PHPSESSID because, I created a simple login-type web app. When I try to login with different accounts, the value of the PHPSESSID is not changing. I got curious if it does okay or not. Because I tried to login in youtube with different account too. But their SID's differ on each user.
My question is:
1) Is what happening on my web app okay ?
2) Is yes, how can I make a session ids per account/user ?
3) If no, how can I fix it ?
I would really appreciate your suggestions.
It partly depends on exactly how you implemented "login." One way to do it is simply to change the user-identity (which, by definition, is part of the data that is stored in the session), while keeping the same session.
Another equally-valid way to do it is to first update the existing session (to show that the user, in that session, is now "logged off") (maybe...), and then to coin a completely new session-id, thus starting an entirely new session, in which you now "log on."
One advantage of the second approach ... and probably the reason why so many sites do it this way ... has to do with the possibility that the user might wish to open a new browser-window, and to log-in to the application a second time, intending to keep both logins alive at the same time. If the session-id token is part of the URL, or maybe is part of a hidden form or what-have-you, such that both session-id's can be retained independently, it becomes possible for the user to do what he has done without conflict. Two parallel sessions exist. In one, he is logged on as "joe," and in the second, he is logged on as "jeff." And so on. One set of browser-windows (somehow ...) carries the "jeff session" token; others carry the "joe session" token.
Fundamentally, a "session" is just a pool of server-side values, identified by the (PHPSESSID ...) token furnished each time by the client. Exactly how you choose to manage it, is at your discretion. It's a design-decision with no "correct" approach.
I have a page that sets a session variable to hold a list of lookups from the database for the page when the page is loaded.
The page also will need to access that list of lookups when Ajax calls are made from the browser.
I'd like to not load the list of lookups from the database for each Ajax call, but I would like to remove the list of lookups from the session if the user leaves the page. Is there a best practice or recommended strategy for doing this?
You can clear the session variable with javascript using something like this
window.onbeforeunload = cleanup;
function cleanup()
{
// Clear session variable here
}
However, this isn't foolproof since the user could always disable javascript, etc. Usually this won't be an issue since the session variable will have a timeout anyway. If you are really concerned, you should remove any current sessions on page load.
Another option, depending on your situation, is to use the Caching.Cache class to hold the values. When you insert the values into the cache, you can set them to expire after a TimeSpan, and just set it for pretty short, like 5 minutes or so.
Note that while sessions are per user, their is only one cache per server instance.
I'm saving the user language choice into the sessions like this:
$this->session->set_userdata('language', $language);
And then I'm setting the language depending on the session data (and making a English , as a default language).
if ( !$language = $CI->session->userdata('language') )
{
$language = "english";
}
$CI->config->set_item('language', $language);
It works good, but the language that user has chosed lasts only for approx. 2 hours - then user have to pick the language again. So the question is, how can I extend the session time to expire (or make it expire only in case if user cleans up the browser data). I can not save the user choice in the database, because I need to also handle guests on my website.
I know I can extend the session time in the CI's config, but I just want it to happend only in case of the language selection, and not for example for accounts sessions.
It is the same session, and it either expires or doesn't. You can't have the authentication part expire, but not the language selection. CI doesn't make it easy to manage multiple sessions, which would have made it possible to store authentication in one short-lived session and language preference in a longer-lived one. As it is, it might be easier to just store language preference directly in a cookie; just keep in mind that you will have to set the cookie again on each request, otherwise it will not get refreshed automatically upon user activity and will expire even if the user is actively using the site.
Can I change the session timeout dynamically? The timeout must be set according to the user role. I tried to use configure::write to change the timeout dynamically but it doesn't work. it seems that for the new session timeout to take efect, you have to reset the session, but resetting the session will loss the login info.
I think using something like the following after you check role membership will get you what you want.
HttpContext.Current.Session.Timeout = 1200;
I think you are right when saying you can't change the session timeout after it has been created, maybe you could look at regenerating one with a new timeout.
But maybe a more easy solution would be to use javascript, you could set a timeout value and when it runs out send an ajax request logging the user out.
This obviously won't work if a user disables javascript but it depends on how secure you want this to be.
Rather than changing the session timeout, have you considered using a variable in the session to store the date/time of the last pageload, so that you can check it on the next pageload?
You could add some code to the beforeFilter() method in AppController to calculate the amount of time elapsed between the last pageload (stored in the session) and now, and if this is greater than the session length for your specified user role, destroy the session. If not, store the current date/time in the session, so that it can be used next time.