I am using WSO2 Identity Server 4.1.0 for user authentication.
When using the AuthenticationAdmin, I am able to use the loginWithRememberMeOption to retrieve a 'RememberMe' cookie, for instance:
admin-b55cdc95-a27e-4e3e-9906-76c18b8437c5
I see in the SOAP response that the cookie has a maxAge of 604800. Does this mean that the RememberMe cookie will be unvalidated after 604800ms / 10 mins?
I tried checking the validity of the cookie after 10 minutes by using the loginwithRememberMeCookie operation. But also after 10 minutes, the result was 'true', indicating that the user was still logged in.
Is it possible to add or modify a timeout, so that the session becomes inactive? If so, where can I modify this?
The RememberMe cookie time is in seconds. So, 604800 seconds mean 7 days.
AFAIK, this value cannot be modified.
Session will time out after the session expiry time. You can change the session time out value. But you can still login with remember me cookie.
Related
I am using Django Basic authentication and Session authentication inbuilt API.In my application I have given a session timeout value of 24 hours in settings.py.
It is working fine but in some chrome browsers it is doing session timeout at every 10-15 minutes.
I have checked session cookie after successful login it is showing correct expiry date.but after 10-15 minutes when session timeouts, cookie expiry date automatically changes.
Please reply if someone has faced some issue.
Is it possible to have a session cookie that expires? Ie. I want the cookie to last maximum 30 minutes, but also get deleted if the user closes his browser. Workarounds are also welcome.
Tried the max-age setting, but that made it not delete when the browser ends.
As far as I know, you can't do both in one cookie. It's one or the other, so either:
set the max-age to 30 minutes to create a persistent cookie; or
don't set the max-age to create a session cookie.
What you could do, however, is create both a session cookie and a 30 minute persistent cookie with different names, and then base your session handling on the presence of both cookies.
We are using the F5 APM to control access to our webapp, but are having some issues regarding expiration rules.
The scenario we want is that the cookie expires 12 hours after creation, or upon browser close, whichever comes first.
Despite our efforts, it would seem that we only have 1 of two options
set the cookies "Expires" property to 12 hours (or max-age)
don't set the "Expires" property at all
The first option successfully allows for the cookie to expire after 12 hours, but if the browser closes, the cookie is persisted until that time, so only one of the 2 conditions is met.
The second option will expire the cookie on browser close, but will not expire if the browser is open for 12 hours or more.
Is there a setting with the F5 APM that will expire the session on the F5 side, while the cookie can remain a session cookie on the browser side?
The best way to accomplish what you are trying to do with APM is to use a session cookie for the APM MRH cookie, and then set the Maximum Session Timeout setting to 12 hours (the value is set in seconds) on the Access profile under Properties in the Settings section (on version 11.x, may be in a slightly different place on v10.x). This will do exactly what you are trying to do.
I have a website which contains several rule sets for different kind of users.
One of the rules (permission) depends on the session expiration.
For instance, an unauthenticated users' session must be flushed when browser is closed however, authenticated users' sessions should live for a constant time.
Furthermore, for authenticated users some keys in the session may be deleted when the browser is closed but other should be kept alive.
How can I achieve this key-based session expiration in Django ?
You can do this by using the set_expiry method on request.session. The method takes either an integer for number of seconds to expire the session, a datetime or timedelta for when the session should expire, the integer 0 to indicate the session should expire at browser close time or None to indicate that the session should fall-back to the default timeout policy.
You should be able to write a piece of middleware that evaluates the criteria you have for session expiration then call set_expiry on the session before processing the request.
When a user login in my website, it returns a cookie with two hours expire. The cookie is not returned in following calls, so after two hours the cookie expires even when the user is still using the website, and then redirected to the login page.
So I think I know the solution, but is it a good practice return the cookie with the "expire" updated in every call?
Cheers.
It's not a huge deal to set a session cookie in every server response, especially since the client is already sending it to the server in every request.
However, you can do better than that. If the client comes in with a cookie that's bound to expire, say, less than 1 hour and 50 minutes from now, you can send them a new cookie that's set to a new, 2-hour expiration date. You can easily keep track when a client cookie is set (and is therefore bound to expire) in your session handling code.
It boils down to why not? It solves the timeout problem, and has no drawbacks.
The only side effect is the additional bandwidth necessary to transfer the cookie, but this is completely negligible. If you do care about that bandwidth, only resend the cookie every n minutes.