Some users got an incurably disabled Join Seder button after entering their names

[douglasnaphas]

I believe that this was users (SS, SD, AB) who had logged in an hour or more earlier, maybe even the prior year, and that I wasn't handling the refresh token properly.

Steps to reproduce:

1. Log in.
2. Wait long enough so the access token will definitely be expired, I think 1 hour is enough.
3. Have another user start a seder.
4. As the first user, try to join the seder.

Expected behavior: you can join fine.

Bug: your Join button is disabled. No error message, no "sorry, you couldn't join."

Check logs for things I think with messages like "no access token" from during the first night of Passover 2021.

[douglasnaphas]

I sent an email to doug@passover.lol about failed joins that has some thoughts about this.

[douglasnaphas]

I'm going to try cutting a feature branch with the refresh token length shortened.

[douglasnaphas]

TODO

• [x] Verify that the subjects in the CloudWatch screenshot I emailed to doug@passover.lol were the affected users.
• [x] Verify that /join-seder fails with a deleted refresh token. The theory is that, because all my cookies are session cookies (verify that's the expected default), they got deleted unexpectedly, so the browser tried to claim it was someone and couldn't prove it.
• [ ] Handle 4XX responses from the API at /join-seder.
• [ ] Maybe do something crazy and test this flow with an automated test.
• [ ] Note observations so far: pretty much only /join-seder has to be authenticated (I deleted the refresh token with an expired access token after joining, and I could submit my libs and get the script, and pick up and read the script from another device); /join-seder still worked with an expired access token; /join-seder still worked with an expired id token.

[douglasnaphas]

I noted a few user sub claims in CloudWatch that are suspected instances of this bug happening. They have log entries like pullTokensFromCookies: user with no access_token: <sub>. Sometimes sub is in the user pool, sometimes it isn't. My theory is that the bug happened when either of these happened:

1. I deleted the user associated with sub. These would be the instances where I can't currently find the sub from the logs in the user pool. I deleted the user pools various times, or swapped out the user pool for one from a totally different stack, especially with respect to people like AB who probably hadn't logged in since the previous year. I could look for those users in the real legacy user pool.
2. The browser deleted the session cookie, maybe arbitrarily, due to refresh, or due to memory pressure. This would be in cases where I can find the sub currently in the current-year user pool. I have one such case (SS), though I can't be sure that the session cookie was deleted. It could also be that my backend is getting confused when one user has multiple user pool entries, each corresponding to a different identity provider. This is the case with SS (Google and Facebook).

Update: of the four that I saw throwing the error in the logs, three are explained by category (1) above (the client sent the user pool sub from the 2020 user pool when trying to join a 2021 seder).

[douglasnaphas]

What do I do when the user that comes with a request is a sub that matches multiple user pool entries?

[douglasnaphas]

If I manually delete my refresh token, but not my access token, while logged in, /join-seder comes back with 500. If I then delete my access token, so that I have neither access nor refresh, then I get 401 from /join-seder.

[douglasnaphas]

I think that part of what has to happen when a person tries to join a seder without the proper JWTs is that the frontend should do a fetch to a backend endpoint that will destroy their JWTs. That endpoint is part of #253, so I am prioritizing that before going forward with this Issue.