We currently have an Angular app that is connecting to a ServiceStack API and sending through cookies. We have a custom credentials provider that either accepts username/ password or an internal id. We noticed that when the internal id is sent through, occasionally the cookies are reject by the validation attribute. On further investigation, it looks like when the internal id is sent through, the ss-opt is set to temp.
Is this the code I need to force permanent cookies?
Also, what is the default expiration of the ss-id and ss-pid cookies?
Yes, the ss-opt cookie just needs to be set to perm i.e ss-opt=perm, either set by client or server.
The ss-id is a Temporary “Session Cookie”, i.e. they don’t have an expiry and expire “When the Session Ends” which usually meant when the browser is closed but some browsers like Chrome and Firefox “Restore last Session” feature will preserve session cookies.
Thanks for the quick response. Yes, this is our understanding as well. We noticed the base authentication attribute returning an Unauthorised error after a random time like 30 minutes. I have also confirmed that the browser session was not closed in the Angular app either.
When the user logs in, they do not set “Remember Me”.
Do you recommend that we still set ss-opt=perm in this scenario?
That’s up to you, but if you’re going to give them the RememberMe option you shouldn’t contradict their preference by choosing to use the permanent cookie instead. That’s what RememberMe controls whether to save their session against their permanent ss-pid or temporary ss-id Cookie.
If you always want them to use the ss-pid permanent cookie don’t show them the option, just always send RememberMe=true.
Whilst the ss-pid Cookie is set to expire in 20 years, it’s only valid for how long their Authenticated UserSession is stored on the Server (i.e. ICacheClient). The ss-pid Cookie gets cleared if /auth/logout is explicitly called or if they clear their own Cookies.
Will This Change Log Users Out?
Authentication cookies should be Secure and HttpOnly
to protect them against man-in-the-middle attacks, cross-site scripting
attacks, and speculative execution attacks. Cookies created through
document.cookie cannot be HttpOnly which means authentication cookies
should not be affected by the lifetime cap. If they are, you need to set
your authentication cookies in an HTTP response and mark them Secure
Only cookies created through document.cookie are affected by this change.The change covers cookies created in first-party contexts as well as in third-party iframes.Session cookies are not affected, they remain session cookies.Persistent cookies that have an expiry shorter than seven days keep their shorter expiry.
We have gotten back to fixing an issue related to Remember Me and SessionOptions.
We have a custom credentials auth provider where we needed to override/ ignore the Remember Me if it was passed in (Basically to handle some legacy apps that cannot be changed at the moment) - I am manually setting SessionOptions.Temporary and also updating authRequest.RememberMe to be false in the Authenticate method.
However, I have noticed that the session is already created by then with the session.Id as the PermanentSessionId (probably because the Remember Me was passed in as true).
I cannot use a global request filter to set SessionOptions.Temporary at this stage as we would need to update Global.asax in a number of APIs for this.
I have added the following lines to my CustomCredentialsProvider > Authenticate method for now. It has passed testing but wanted to confirm whether this is all that is needed.