Support multiple accounts + switching between them

[kesslermaximilian]

Now that the Hanabi Pro Hunting League has started, alt accounts have become more common. It'd be nice to be able to log in to multiple accounts (from the same browser) at the same time and have some switch button for them.

Probably, we'd have to restrict switching to only be available while not currently playing a game, but even switching while in the lobby seems reasonable.

Is that a feature you could imagine adding?

[Zamiell]

Probably not tbh, I would like to keep the interface relatively simple.

How would it work?

[Zamiell]

Note that you can log into infinite accounts from one browser window already

[kesslermaximilian]

Note that you can log into infinite accounts from one browser window already

How can you do that, without having to log out + in again?

[Zamiell]

you just log out, open n tabs, and then login n times on n tabs

[kesslermaximilian]

Hm, but that breaks once you reload the page on any of these tabs (which sometimes you also need to do since the site hangs)

[Zamiell]

in the case that you need to refresh one of the tabs, then you have to logout and login again on that tab, because it only remembers your last cookie. doing this is annoying, but not that bad in the grand scheme of things.

maybe a good pull request would be to implement some kind of tab-based cookies. i imagine we could have a scheme such that if the recently logged-in username for the tab is different than the recently logged-in username globally, then the tab username would take precedence over the global username when the "auto-login" feature triggers.

[Zamiell]

i will also note that i feel it is much better UX to have an account dedicated to a tab, because switching back and forth between tabs is completely seamless. i feel like it would be more painful to switch between accounts with e.g. a UI feature similar to the gmail multi account dropdown selector.

[kesslermaximilian]

Yeah, binding it to tabs seems like a good idea, I like that.

[Zamiell]

i dont think this is possible right now because there are no tab-based cookies. the golang server uses a Set-Cookie HTTP header, which applies to every tab.

i guess that I can sacrifice the security of the server/client by transitioning to a less secure scheme that doesn't use cookies. Instead I can manually authenticate the websocket connection once connected, and then keep track of which websocket connections are currently authenticated. that's kind of ugly though, because then I have to re-authenticate every websocket command that comes in. in this scheme, the username + password hash would be stored clientside via both localstorage and sessionstorage: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage and then we could have sessionstore override localstore if present.

I think this won't happen until we migrate to the typescript server though, because I don't want to change golang code.