Users with the same *display* name will steal an existing users controller and character upon connecting
If a user connects with a display name that is the same as an already connected user, the first user will be unable to control their character, and the newly connected user will inherit their position and entity.
Steps to reproduce:
- Two accounts, different usernames, but similar display names
- Join the same game
- The first player is no longer able to control
The username is unique from Firebase and would be a reasonable fix to use, but it is still possible to just connect with whatever user_id you want using the client directly.
The correct solution requires some restructuring and adding auth in the networking layer, something which me and @pierd have discussed a bit before
Yes, we need some kind of signed auth that one gets from the website/api and that the server can validate. Next to it can be some randomly generated user identifiers that never clash with the signed ones.
Also user identification shouldn't be tied to what is displayed.
See also https://github.com/AmbientRun/Ambient/issues/975#issuecomment-1741817071
Should we make the connection-steal apply if and only if the stolen-from user hasn't responded in the last 10 seconds? (or some amount)
That way, you/someone else can't accidentally steal a connection from yourself by double-connecting, but you can steal it if the old connection is dead.
I'd solve it with proper auth so you always steal from yourself and nobody can steal from you. That's also how we did it for reconnects in calling.
Yeah, just thinking about how it would also work in authless environments (e.g. I just got bit by this because I have a user-id specified in my settings and connected to my dev server with a second client that also used that user-id)
Maybe multiple user profiles in settings or just an option for override from cli arg? The random one (when there are no settings) or overridden one (with cli arg) would be in authless pool which is free for all, we just make the entropy big enough not to cause problems with random users kicking each other out.
Yeah, --user-id already overrides a preset ID. You just have to remember to use it - I forgot last time, and I figure others will too, so it would be nice to have a failsafe in that case that'll prevent you from hijacking yourself. (Or, if your existing name is very generic, like "Phil", stop you from hijacking someone else's name)