I am developing a java web application in which I have configured session-timeout to be equal to 4 minutes.This application also uses cookies.
My problem is after 4 minutes of inactivity the HttpSession expires but the cookies remain in the browser (age is set to -1). Is there any way to delete cookies after session timeout?
P.S. setting cookie age equal to 4 minutes wont help.cookies should be deleted after 4 minutes of inactivity .
If you set the cookie age to 4 minutes, and reset the cookie age every time your server sends a response, then the cookie will time out after 4 minutes of inactivity.
Related
Scenario:
We have our custom IDP(Spring Boot) and 2-3 clients(Spring Boot) in Keycloak. We're letting users authenticate through OIDC flow.
Keycloak SSO Session Idle: 30 Minutes(Default)
Client 1: Session Expiry > 45 Minutes
Client 2: Session Expiry > 15 Minutes
Problem:
When Client 1 gets login their session expiry should be set to 45 minutes, but after 30 minutes idle screen it gets logout
When Client 2 gets login their session expiry should be set to 15 minutes. After 15 minutes client session gets killed from a client app server but it still presents in keycloak. So till 30 minutes session is still present in keycloak. And if we hit URL we get logged in.
Question:
Can we set session expiry as per the client's request? Or in another way can we override keycloak SSO Session Idle through auth request or through API?
We simply want to use the client's session expiry/timeout.
I am implementing Identityserver where sliding expiration value is set at client side. So is it secure?
Does asp.net session timeout work in similar way? i.e. client side comparison?
Just need theory about whether session timeout is client side thing or server side thing.
What exactly happens when session timeout. Cookie clear or any server value clear?
Sliding expiration means that each time the session is accessed it will reset the timer back to 20 minutes again.
Also, by default sliding expiration is used so you don't need to write any code.
If the user does not access the session for the timeout period then the session will expire. If the user accesses the session at(for instance) 3:01 then the session will expire at 3:21. If the user accesses the session at 3:10 then the session will then expire at 3:30. It is always 20 minutes after the user last accessed the session (that is the meaning of sliding expiration). If the user does not access the session in that 20 minutes then the session will expire.
Hope the answer gets you a glimpse of sliding expiration...
How to set expired time for Sentry auth / token?
I Need to set the time to 60 minute or 1 day maybe.
Is it can be set at config? but i don't find the setting for expired time login.
Go to config\session.php.
Change the lifetime value to any number of minutes. Sentry will use that value as its session expiry time.
As per the laravel documentation:
| Here you may specify the number of minutes that you wish the session
| to be allowed to remain idle before it expires. If you want them
| to immediately expire on the browser closing, set that option.
I'm trying to build a simple web application with a user login.
I found this function in another post here.
func initSession(r *http.Request) *sessions.Session {
session, _ := store.Get(r, "mBoxStore")
if session.IsNew {
session.Options.Domain = "localhost"
session.Options.MaxAge = 10
session.Options.HttpOnly = false
session.Options.Secure = false
log.Println("Create New Session (cookie)")
} else {
log.Println("Use Old Session (old cookie)")
}
return session
}
The cookie expires after 10 seconds, but when i reload the page after e.g. 1 Minute
it use the old (expired) cookie.
In my browser (Firefox) i see the cookie with the right expire date.
I think it should create a new session with a new cookie or it is wrong ?
any tips ?
The reason you're seeing Use Old Session (old cookie) is because the session options are only being set when the cookie is first created. Each time you access the cookie before it expires (isNew == false) Options are not being set, and the defaults are overriding those you set on creation of the session. The default MaxAge is 86400 * 30 (one month).
You can verify this by:
Clearing all cookies for the site (i.e. localhost)
Bringing up a route in your browser
Checking the expiry date on the freshly created cookie - you'll see it's now + 10 seconds
Wait out that 10 seconds.
Refresh the page - your log should confirm it's a new cookie.
Now refresh the page before the cookie expires (i.e. within 10 seconds)
You'll see the expiry has an expiry of now + 1 month (the default).
This is why I suggest setting your session options once, on application startup. Only deviate if you are setting shorter cookie lifetimes for authentication security purposes, and in those cases use a different session name (i.e. _csrf_token with an expiry of 4 hours).
The code snippet you're using isn't really ideal either as it completely ignores any errors encountered when trying to retrieve a session. You might run into errors if your underlying session store is broken, and/or the user has cookies disabled.
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.