fix/prevent logout in login pages

[alexanderleegs]

Problem

Possible fix to https://linear.app/ogp/issue/ISOM-1009/sgid-logins-are-failing-silently - cannot verify as issue is hard to reproduce

This PR prevents the calling of the logout endpoints on our login pages, i.e. / and /sgid-redirect - as their interaction could possibly be the source of failed sgid logins. As these pages are also inaccessible if the user is logged in, since they will be redirected to /sites, there is no reason to call /logout from these pages regardless.

Tests

• Login with sgid
• Login with email

[seaerchin]

press x to doubt

[seaerchin]

actually on reading this, it looks very suspicous. if i'm on / or /sgid-callback and i get a 401 unauthorized, i'm not logged out because there might be another request in flight to sgid?

[alexanderleegs]

My guess is that the unhappy flow on /sgid-callback is -

1. verify-login is called, and whoami is called, since it's part of the login context
2. whoami resolves with 401 (expected, since user isn't logged in yet). This triggers logout
3. verify-login resolves. The cookie with the user data is set
4. logout resolves. The cookie with user data is removed
5. User gets redirected to sites. They no longer have a valid session cookie, so they get logged out when whoami triggers again

I think users who aren't affected by this just happen to have steps 3 and 4 swapped.

Logically i don't think it makes sense to call logout from the login pages anyway, since logged in users should be redirected away anyway, and logged out users are already logged out

[harishv7]

In this case shouldn't verify login be awaited to resolve before whoami is called? Are we able to make it sequential?

[alexanderleegs]

I think this might be possible! I'm opting for the quickest solution here to test it out though, since we can't be sure that this is the actual source of the issue

[kishore03109]

wait wait sgid had a legit incident, lets not push faulty code here as a knee jerk reaction. well, unless they are not related ah, lmk if I am mistaken

[harishv7]

Don't have full context on the inc, but general thoughts:
Can we identify root cause for the sgid login using traces/logs, or add monitoring to recognise the sgid silent failures before making logic-level changes? For all we know, it might have been just that 1 user, and might have been related to the sgid downtime.

[alexanderleegs]

Shouldn't be related to the sgid incident - we were having this issue before their spike in cpu util! We've also been having this issue on and off, and sgid + our sgid login endpoints are behaving as expected - the failure seems to be from a generic 401 error from whoami, see here for verify-login succeeding, but the user still being unable to login

My suspicion is because of this strange behaviour on login - notice how we call /verify-login, then
/whoami, but /whoami returns a 401, which triggers the /logout.

Funnily enough this is actually a successful login - whoami gets triggered again later and actually returns 200 this time, so the login was successful

[seaerchin]

reading through this, i think it makes sense. if i start in a logged-out state, then it doesn't make sense to call logout (because i'm already logout).

i'm not entirely sure this is the fix going forward but the blast radius is limited here so i'm ok w/ merging this in and trying