You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Raised by Wellcome, there appears to be a bug where a user can end up with a cookie that references a UserSession that is expired in the database but the cookie expiry is being extended,. This means that if another clickthrough agreement is accepted the previous cookie is not removed and all images with clickthrough role return a 401.
Steps to replicate
Open an item that requires clickthrough auth and accept agreement (note default TTL for role, default is 10mins)
Confirm that you can view images that require clickthrough (e.g. open one in browser) - get 200 / view image.
Note dlcs-token-{customer} cookie issued and note expiry.
Note expiry of corresponding AuthToken in database.
Wait more than TTL and request clickthrough image again (images that require auth have a cache-control:private header sent so try a different size/rotation/quality/format to ensure it's fresh) and confirm response is 401.
The dlcs-token-{customer} cookie will still be present with extended expiry.
AuthToken in database expiry is in past and doesn't update.
Example links for Wellcome where this was noticed (see slack for more details)
The cookie expiry should only be extended if the session is validated but cookie is extended by AuthToken.TTL, rather than updated to match AuthToken.Expires so they can end up out of sync - could this be an issue?
Is it possible that cookie value is not being correctly updated but expiry is? AuthCookieManager.SetCookieInResponse() uses cookie-value from database but do cookie headers need cleared first?
Issue noted was DLCS running behind CloudFront - does that affect anything?
The text was updated successfully, but these errors were encountered:
donaldgray
added
bug
Something isn't working
auth
Authentication/authorisation tickets for accessing restricted content.
labels
Jul 12, 2024
The issue for this was that cloudfront was caching authentication requests for cookies due to the authentication request looking like the same request every time (specifically the action token response here). This caused the caller to think that the dlcs-token-* cookie was extended, when in reality there had been no extension. This tricked applications (like the Wellcome works page) into requesting images that were forbidden due to an expired token
In order to fix this, no-store headers were added to authentication endpoints meaning that cloudfront no longer caches them.
Raised by Wellcome, there appears to be a bug where a user can end up with a cookie that references a UserSession that is expired in the database but the cookie expiry is being extended,. This means that if another clickthrough agreement is accepted the previous cookie is not removed and all images with clickthrough role return a 401.
Steps to replicate
dlcs-token-{customer}
cookie issued and note expiry.AuthToken
in database.cache-control:private
header sent so try a different size/rotation/quality/format to ensure it's fresh) and confirm response is 401.dlcs-token-{customer}
cookie will still be present with extended expiry.AuthToken
in database expiry is in past and doesn't update.Example links for Wellcome where this was noticed (see slack for more details)
Thoughts:
AuthToken.TTL
, rather than updated to matchAuthToken.Expires
so they can end up out of sync - could this be an issue?AuthCookieManager.SetCookieInResponse()
uses cookie-value from database but do cookie headers need cleared first?The text was updated successfully, but these errors were encountered: