This may sound like a very trivial doubt, but I need some help here.
I have set up Application load balancer with OIDC authentication. After logging into my application, using chrome developer tool I looked into the client application cookie. Found that AWSELBAuthSessionCookie-0 and AWSELBAuthSessionCookie-1 have an expiry 2070-10-04T05:02:12.122Z which is almost 50 years from now. Since the ALB isn't forwarding this cookie to my application (EC2) which resides behind the ALB, I am unable to reset the cookie's expiration. I am using Flask to read the headers. Any leads to reduce the AWSELBAuthSessionCookie's expiry will be helpful.
quite an old question already but here are my 2 cents:
invalidating a cookie is somehow just a set-cookie with an expired date, so I don't think you need to be able to read the cookie from the request to invalidate it. I have not tried but I would just do something like
Set-Cookie "AWSELBAuthSessionCookie-0=deleted;path=/;expires=Thu, 01 Jan 1970 00:00:00 GMT;"
for the 2nd point (from #codematix), to logout you need to invalidate the auth cookie AND to redirect the user the logout page configured in your IDP (probably to also invalidate the tokens, otherwise the ALB would just revalidate the tokens and re-create a session). See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#authentication-logout-timeout
I think you are confusing the ALB session (JSESSIONID cookie if I recall correctly) with the auth session cookie here.
Once again I am no time to validate this but hope that helps :)
I too have the same question, in my case it is being set to Expires=Sat, 29 Aug 2071 22:16:30 GMT. And I am unsure, even when I have set the Session timeout to 14400 seconds which is about 4 hours in the ALB authenticate rule.
It is quite unexplainable as to why this large expiry time would be set despite an explicit smaller value.
Related
I visit the Information Commissioners Office (ICO) https://ico.org.uk/ which is the commissioner who is in charge of things like GDPR and cookies in the UK.
They have the option to opt out of cookies, which I duely did. I then refreshed and I could still see cookies being load for Google Analytics.
A few days later I returned and the cookie must have expired. Were my original findings due to browser cache? And if so, is there a way to force browsers to forget cookies? I would find this more compliant with the users wishes.
I think if a cookie can expire, then perhaps you could set the expiry date to now when a user opts out. Or set the cookie to 1900 or something similar so it expires. Or set it to null if that would make a difference.
Is it possible to remove a cookie instantly when a user opts out, or is that entirely down to the browser settings?
Yes. To force a cookie to expire, return one with your response with a matching path and name, but an expiry time in the past. The browser will consider it expired and delete it.
Pretty much every site using Google Analytics is going to be betraying your wishes (and breaking the law, at least in the EU), since that's what it's default configuration does, and it's very rare than anyone changes it to anything else.
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.
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.
Is it posible to notify user that session has expired? Can browser act as server and receive such notifications?
One solution would be to generate JavaScript that does countdown on client side and notifies client in the end, but I am iterested if it is postible to do it the first way?
And what are the consequences of first approach? Are there any security concerns?
What would be posable implementation in django, for example?
You could have the JavaScript periodically poll the server for notifications (every 30 seconds, say), using XMLHTTPRequest to check a URL. If the session times out, the server could put something at that URL that indicates it, and then a notification could be popped up. This is how Stackoverflow implements the notifications that someone else has answered a question already if you're in the middle of composing an answer.
You may wish to look at comet, although I think a javascript timer would be a much better solution being less likely to break, and easier to implement.
I can't think of any security implications as you are only providing an expiration notice, not actually doing any authenticating in that step.
You're looking for some sort of comet-type thing. Probably the easiest "server-push" you can do is polling the server.
In fact in Django, there is not server-side expiration if you use filesystem or database engine => is it your client cookie session id wich expires. Otherwise, if you use cache-based session, you could set the cache expiration to a greater value than the session cookie expiration.
An then, simply declare a cookie without expiration to flag the client browser at login, and check in every page the session id :
if there is no session id cookie but your "cookie flag", the session is expired. There is no need to check the server.