If you don't set an expiration date on cookies, do they draw the expiration date from the browser settings (if there are any), or do they have a default expiration or something?
If you don't set an expiration date on cookies, do they draw the expiration date from the browser settings (if there are any)
No, if you don't set an expires header for a cookie the cookie is temporary. There are 2 types of cookies: persistent and temporary. Persistent cookies (one for which you specify the expires header) are saved as temp files on the client computer and survive browser restarts (for the duration of the expiration period or if the user clears them).
Temporary cookies on the other hand live only inside the memory of the current instance of the browser. Just as persistent cookies they are sent along each request (without expiration) but once the user closes the browser they are gone forever.
Related
I am using a mix of a browser (Xamarin webview; to initially login and getting an access token that expires in 1 hour) and httpclient (to access my webapi endpoint). When the token expires I request a new one using the /connect/authorize endpoint using a httpclient (with the cookies copied from the webview) to get a new access token.
This works alright as long as the cookies aren't expired.
I've set up identity server to have a sliding expiration of 1 day on the authentication cookie (CookieOptions: ExpireTimeSpan/SlidingExpiration). I thought that this would result (besides getting a new valid token) in receiving new cookies on every request to the authentication endpoint, effectively keeping me logged in. The problem is that the expiry of the initial cookie that I received when logging in using the webview is used. So no matter how many times I access the authorization endpoint, I'm still logged out after a day and I can't get a new token from the authentication endpoint anymore.
Assuming I'm not completely taking the wrong approach, what requests should get me updated cookies (IdSvr? IdSvr.Session? which do I need anyway?) with a new expiry date, so I stay logged in to IdentityServer?
Note: I did take a look at refresh tokens, but these aren't available for implicit flow. And I think I need implicit flow in my case because I shouldn't save a client secret in a distributed Xamarin app. Using the cookies seems like the best alternative.
Note to self (and others): the authentication cookie is the one that's important. For the record: that's the idsrv cookie.
Then the thing that confused me during testing: calling the /authorize endpoint will only return a new authorize (idsrv) cookie when at least half the expiration time has been passed.
This surprises me a bit, because that would mean that:
8:00 log in with sliding exp of 4 hrs (expire time: 12:00)
9:59 request to /authorize endpoint (expected new expire time: 13:59)
12:01 request to /authorize again
The 12:01 request would fail miserably, because the 9:59 call did not get me an updated cookie...
Had I made de second request two minutes later at 10:01, I would have gotten an updated cookie with expire time of 14:01.
Conclusion: sliding expiration seems only be sliding when half the expiration time has passed.
Given an example here for a normal web app.
Traditionally, we use session and set timeout = 30 minutes. if session expires we will redirect user to login. (Expired time will be extended when user/browser interact with web app)
Using JWT, how to achieve that?
I know something about "token refresh", when short-time token expires it will refresh a new one using refresh-token.
But it looks like it don't care about whether user is interacting with web app or not. So as long as refresh-token is alive, the browser can always get a new short-life JWT.
So the question is: How to extend token expiring time if user is not active for a set period using JWT?
When the user interacts with your server then your server can decide to issue another JWT with a new expiration time (not at each request but e.g. 5 min before the current JWT expiration time). If the client receives a new JWT, then it replaces the old one.
When the user does nothing, no new JWT is issued and the JWT will become invalid after the timeout.
If the user is active, then issue a new JWT every time the user enter in the web application and every period of time (for example 1 hour)
If the user is not active but the browser is open, it can request a new JWT to server in background. The token must be requested before expiry time and then replace the token in localStorage or cookie. This technique also can be applied to standalone applications
If browser can not request a new token (closed, not active, etc) then the token will expire and you can redirect user to login in the some way that if server session expires
Check this JWT (JSON Web Token) automatic prolongation of expiration
While load testing using loadrunner all my virtual users are getting logged off from application after 30 min. Looking in detail came to know that authentication cookie is getting expired even though we have continuous activity performed by users.
Now we are trying to update the cookie explicitly after each action to prevent expiration, but not sure how server identifies that authentication cookie is expired. The cookie has only encrypted text and no explicit title mentioning expiry time.
What information in cookie should be updated in authentication cookie to prevent it from expiring?
Cookie Information:
Cookie:
.ASPXAUTH=66DD4AB74239F00D553BA9640D3AD3F284F47DEC315FD6789AE3FB8D67D2A46A4E89EDB45845C921A7557BD6B39A12EE07188D1009D581AA7AAF6743710653AE44EEF2733CC16082C595D7AE7C73D3E7E3D44BA1BAEEFEB1BF5F98B35C5F8429670FFDD5586E03BB3138C5B78945D82702BDD7C4;
path=/; HttpOnly
Tell us how you are managing session state in your script. Generally if you are cleaning all cookies and instantiating a new session for each iteration you should not run into this. If you are attempting to maintain some sort of singular session state for the entire length of your test I could see how the server would potentially kick you out after your original session technically logged out of the system (as part of a business process).
Also, do you have explicit cookies noted in your script? If so, you may want to consider commenting these statements out as LoadRunner will manage cookies automatically. As part of your burn in consider running a singular virtual user for 30 minutes to an hour to see if you experience this on a single virtual user level. It's a lot easier to fix for a single user and then projecting to load than it is to try and figure out what is happening across dozens or hundreds of users experiencing a similar issue.
From what I can gather the Server keeps track of the expiry time of the cookies, and it's also the server that updates the expiry time, meaning you as the client have no control over this.
I assume the flow is this:
The browser or LoadRunner Script will always send the cookie and the
server then verifies it's expiry time on the server side, redirecting
you to the login page if it has expired.
I've had this happen to me, and solved it by visiting a special page on the server that "updated the client session expiry time". Perhaps you have a similar situation?
For my application we have not mentioned any explicit timeout and forms authentication cookie is set by default with expiration time 30 min and Sliding Expiration true. I came to know that the sliding expiration will reset the expiration time after 15 min.
In the cookie the only information I see is encrypted text and expiry time is not mentioned explicitly. Then How application tracks this cookie to expiration. Will the encrypted text gets updated after 15 min or is this tracking happening on server side for a particular session?
If the cookie is between 0 and x minutes away from expiration, I would like to refresh the expires value of that cookie to some set value (if the cookie is already expired, I do not want to refresh it).
How would I accomplish this with CGI::Cookie and CGI.pm?
Cookies sent by the browser do not expose their expiration time; they are either sent or they aren't. To know when it is going to expire, you have to store the expiration time in the cookie value in some parseable form.
If the cookie has been set, then it will be sent to the server. If it has expired, then it won't be.
Just test to see if the cookie exists, and refresh it if it exists.