In magento, the value of the cookie life time we set from the admin control panel , is browser dependent.
I set the cookie life time value for my default store configuration scope as 600 seconds.
I want to know if this value is browser dependent. Suppose I login to my store at 10 20 am in firefox and 10 25 am in internet explorer, by using the same login id. Then what will happen after 600 seconds, to both these browsers.
Sessions are in most cases tied to the useragent (browser), thus logging into the same account from two different browsers/browser sessions will create two different server-side sessions with each one having it's own expiry time. Some systems don't allow multiple sessions to be started for the same account, but in my experience this is not the case with Magento.
Related
One user can log in through multiple systems with various IP addresses, so is there any way to deactivate one of his sessions? (or all other sessions except the current logged in one) if yes, how?
The thing I want to do is exactly like Telegram which you are able to close any of your activated sessions.
The question is not new here, it appears a couple times a month in different interpretations, and the answer is still: there is no such feature out of the box, but there are a couple approaches:
The first one is to use Reference Token (instead of jwt by default), then look through the persisted grants database and logout all the sessions for the target userId.
The other approach is to implement your custom session store based on a database (instead of the cookie based by default). Then you again have access to all the clients logged in with the given user id. Here is my old (but still valid) example of a hybrid (cookie + IDistributedCache such as REDIS) extension for the DefaultUserSession. Here you have to be careful with access token lifetime (make it reasonably short), as a jwt once issued can not be invalidated before its normal expiration.
I've been doing the exercise in
https://www.railstutorial.org/book/basic_login#sec-exercises_logging_out
It's says that I should confirm that the session is deleted after logging out,
Does deleting the session using
session.delete(:user_id)
will make the cookie in my browser (Firefox), disappear?
Also, I've noticed that the content of the cookie changes when I'm visiting different pages in my website, is that an intended behavior? I also get cookies when visiting my website, for the first time, even when not logging on
No, it will simply remove the key from the cookie as we can see in the source code https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/request/session.rb#L146.
It will in effect kill the authenticated but the cookie will still be there (it just won't say the user is authenticated anymore).
Also, I've noticed that the content of the cookie changes when I'm visiting different pages in my website, is that an intended behavior?
Yes, if you're using CookieStore (which is the default way in Rails) all the data is stored on the cookie. So if you add or change fields, the cookie changes . (You will notice that the data is encrypted so this is secure). http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html
I also get cookies when visiting my website, for the first time, even
when not logging on
It makes sense that Rails starts the session even before any authentication is happening - it's basically just an identifier without any data any it yet. A "Session" doesn't have to mean an authenticated user, you might want to save the user's preferred language or the time he opened the website even before he's authenticated.
Im using autologin on my MVC 3 website.
How do I best handle this problem:
A user signs in at his own computer (and gets a 30 day cookie)
Same user signs in at a friends computer (and gets a 30 day cookie)
Its now possible to autologin in at both computers. The user realizes this and changes his password but his friend is still able to autologin from his computer until the cookie expires.
How do I best handle this?
I could of course set at date on the user when password changed and check this up against the date in the cookie.
Or am I missing something?
I know what you're saying, but I think you're implying an association between the "remember me" function and the "password change" function which in practice, isn't there. The auth token you get when authenticating is not generally tied to the value of the password (i.e. when using the membership provider), after all, you're logically keeping the identity authenticated across sessions and in this regard, it works just fine.
To be honest, this sounds like more of a user behaviour problem than a technology problem. In your use case, someone is consciously asking the browser to allow them to remain authenticated for a long period of time and doing so on a machine which they have no control over. Of course I'm assuming you have a "remember me" checkbox and if you don't, there's your answer right there.
The other thing you might want to look at is what OWASP talks about in part 3 of the Top 10 - Broken authentication and session management. This link will put it in a .NET context for you but in short, it talks a lot about reducing the opportunity for exactly what you're describing to happen by things like eager session expiration, disabling sliding sessions and obviously giving end users the control to expire the token at session expiration and log out at any time.
Don't yo have Remember me checkbox on your login form. The value of this checkbox will dictate whether you are going to create persistent cookie or not. if you don't create persistent cookie, it will expire as soon as session ends. In this scenario you user can leave Remember me checkbox unchecked when logging in on his friends computer. If he doesn't he is calling for trouble himself.
we have a question about ticket-granting tickets expiration policy. We are using cas authentication. The TGT expires after 2 hours whereas java session exiperes after 30 minutes.Our problem is that if a user works only using a web application more than two hours and than tries to use another web application, the ticket-granting ticket is expired and so the user must re-login, although he can work in the first web application.
Is there a way to renew ticket-granting ticket while the user is working in the first web application??
Sadly, short of doing some magic, as of CAS 3.4 (when I was looking into a very similar problem) the answer is no.
If you absolutely have to implement this feature, the best idea I've run across (a co-worker came up with it, not me) was to have every page of your apps use Javascript to "ping" your CAS server (a simple AJAX request that doesn't care about the return will work), and implement a custom TGT Expiration Policy that keeps track of the last ping-back and expires the ticket if the last ping was more than X seconds ago. However, this approach requires a considerable amount of hooks into the CAS framework and I would recommend against it. I'd provide code but it has been too long since I really dug into CAS's internals.
If I have a site that uses cookies for authorisation, so when the user returns they don't have to login again.
If for some reason the site admin cancel this users account what is the best way to check for this. I don't want to have to hit the database every time the user visits a page to make sure their account is still live.
So how should I handle this situation?
Several options. Set a shorter expiration on the cookie so they'd have to get authenticated afresh sooner.
Another alternative is to have any important action require that they be authenticated against the database. Thus you would only be hitting the database for more privileged actions that would more likely overlap with the high priority things you'd want a cancelled user be unable to do.