Hornwitser
3f492edea2
If a session is rotate in the middle of a server side rendering then some random portions of requests made on the server side will fail with a session taken error as the server is not going to update the cookies of the client during these requests. To avoid this pitfall extend the expiry time of sessions to be 10 seconds after the session has been rotated. This is accomplished by introducing a new timestamp on sessions called the rotateAt at time alongside the expiresAt time. Sessions used after rotateAt that haven't been rotated get rotated into a new session and the existing session gets the expiresAt time set to 10 seconds in the future. Sessions that are past the expiredAt time have no access. This makes the logic around session expiry simpler, and also makes it possible to audit when a session got rotated, and to mark sessions as expired without a chance to rotate to a new session without having to resort to a finished flag.
1.2 KiB
Server-sent events
To update in real time this application sends a text/event-source stream using Server-sent events. These streams use the current session if any to filter restricted resources and ends when the session rotates timeout is hit, necessitating a reconnect by the user agent. (If there are no session associated with the connection it ends after the session rotates timeout).
Events
Upon connecting a "connect" event is emitted with the session the connection was made under. This is the primary mechanism a user agent discovers its own session having been rotated into a new one, which also happens when the access level of the account associated with the session changes.
After the "connect" event the user agent will start to receive updates to resources it has access to that has changed. There is no filtering for what resoucres the user agent receives updates for at the moment as there's not enough events to justify the complexity of server-side subscriptions and filtering.