User System

The user system is what does the actual work. It takes the user requests and queries Google for responses. It makes effective use of caches to avoid over polling. It makes frequent use of Go's concurrency to allow for re-use of existing setup.

Overview

• Have each user session run in seperate go routine
• Each connection registers to user session to receive broadcasts
• Each user watches the document once and broadcast changes.
• Each document watches from user on the server, to broadcast changes quickly without polling google.
• Each document per user gets go routine to poll changes.
• Each document connector has go routine to poll in change then broadcast to group
• Separate polling system to talk to Google to limit connections and avoid hitting Google to often or hard. (?)
• Listing and the like are handled by the user session, cached as appropriate.

Connection setup

Before anything interesting happens, auser session has to be created. There are two possibilities:

1. The user has previously started a session. We should then resume this session.
2. The user has never contacted us before. Inwhich case we force the usual authentication flow on to them. Note that if a previous session is deemed invalid (bad OAtuh token, or we don't know about it), this step is jumped to 2 anyways.

Prep work

Due to the fact websockets can't set cookies, a POST request to /api/generate_cookie is required. To avoid session fixation, a new cookie is always set unless a valid session exists with the old cookie.

Previous session

To establish this session, we need the session id. To verify the session, we use the cookie we pre-set.

1. On web socket connection, verify we have a session cookie and the origin is the expected domain. Close the socket if this fails.
2. Lookup the user session in the live session list. If found, reconnect the live session.
3. Otherwise, check the database. If the session is found in there, spin up a user session.
4. Otherwise, start a new session.
5. The client should try to verify the socket is up. On failure, jump to new session. Otherwise the application can start making requests.

For now, if a session reconnects the old data for the socket is dropped. Any unanswered queries should be re-sent. It is possible old queries may be sent down a new web socket connection. Code should be prepared for this. Random push notifications may be delivered as well, but all sent data must be valid for the session.

New session

In this case, a call is provided to start the OAuth flow with Google. The usual takes place, and various pieces of data are put in place. User data can then be retreived.

1. On connection, verify the domain origin and the session cookie are in place. Close the socket if this fails.
2. The client can then request a new OAuth request URL. Optionally the page can include a return path, but is ignored for now to protect against open redirect issues.
3. The client redirects to this URL.
4. Google OAuth flow happens, at the end redirecting the user back to the OAuth receive page.
5. On success, grab the code, and redirect back to the user's page.