mirror of
https://github.com/GSA/notifications-admin.git
synced 2026-02-09 04:43:54 -05:00
72acc4ebdc
we have a hunch that some session related issues that we've seen over the last few weeks might be related to weird race conditions where cookies set by subresources (image previews of letters on the send flow) arrive just as the img request is cancelled because the user has clicked on a button to navigate to a new page, but still manage to set the cookie? We're not entirely sure what's going on, but we've got a hunch that not setting cookies on image fetches sounds sensible. Images are always loaded as a subresource (ie: through a `src` tag in an html element), so they should never need to change the cookies, so this seems sensible. We've done this by creating a new blueprint that doesn't set session.permanent, and doesn't call `save_serivce_or_org_after_request` either. cookies are sent back to the browser if: `sesion.modified or (session.permanent and 'REFRESH_EVERY_REQUEST')` (where the latter is a config setting). Turning off REFRESH_EVERY_REQUEST (which is True by default) means that we will only update the sesion if it's been modified. In practice, literally every request is modified in the after_request handler `save_service_or_org_after_request`. This is accidentally convenient, as it guarantees that we'll still send back the cookie normally even though refresh_every_request is disabled. Sending back the cookie updates the expiry time (20 hours), so we need to keep doing this to preserve existing session timeout behaviour.