Session expiration is not handled gracefully by client

[jonathanperret]

Describe the current behavior

If a document is open while your Grist session expires (due to COOKIE_MAX_AGE), you can currently continue to edit the document seemingly normally, and the changes are correctly persisted.

You will only have to sign in again if you navigate away from the document, i.e. by returning to the workspace.

This is clearly enabled by the fact that most document operations go through a WebSocket and session validity is only checked when opening the WebSocket.

But some document operations, such as renaming the document, modifying access rules, listing snapshots… do not go through the WebSocket and will fail in that situation.

The Grist client code unfortunately does not handle such failures gracefully: an error message may pop up without obvious recourse, or the entire page may go blank with an error popup.

Additionally, when a document reload is triggered by another user modifying the access rules, or by the loss of the WebSocket connection due to network conditions or a doc worker restart, the document is not reloaded properly, showing an error instead.

Steps to reproduce

1. Sign in to a Grist instance (such as getgrist.com) and open a document
2. Clear the associated cookies (on getgrist.com,grist_sid_prod) from your browser
3. Observe that you can still edit the document, formulas correctly recalculate, etc.
4. Try to rename the document: observe that the operation fails and an access denied toast appears in the bottom left.
5. Go to Access Rules, make any change and click Save: observe that the page goes blank with a generic error popup. Note that the popup is unnecessarily worrying because the user only needs to reauthenticate for the document to load correctly. Also, clicking outside that popup leaves the user on an almost blank page.

Describe the expected behavior

Whenever a call to the server is made that fails because of an expired or invalid session, the user should be prompted to reauthenticate (which may automatically succeed in the case of an existing SSO session).

Where have you encountered this bug?

• On docs.getgrist.com
• On a self-hosted instance

Instance information (when self-hosting only)

No response

[dsagal]

This is a very good description and explanation of the problem, thank you!

For anyone looking into fixing it, I wanted to point out another problem with similar symptoms. A user can sign into Grist with multiple accounts (using the "Add account" option in the user menu). For example, I am often logged in with both work and personal email addresses. Which account is active is a setting that's associated with each org, and saved in the user session. If I am logged in as A in one tab, and then in another tab for the same org, I switch my account to B, then a document that has been open in the first tab will continue working over the websocket, but operations that make new calls to the server may fail with confusing errors (as for an expired session), because the server will interpret them as made by account B, which may not even have access to this document. The solution may not overlap with than for expired sessions, but I wanted to point it out in case it does.