Closed shawnd closed 8 years ago
instead of just auth account name it would probably be more useful to get auth ID instead. I'm waiting on frozen sand to get back to me to see if they have an api that we can use to associate urban terror accounts with ftwgl accounts.
i'd probably be more interested in adding a 'unique id' to the team member to make it a but more generic
i don't plan on getting rid of gravatar right now, but rather we would enhance user profiles with the ability to upload avatars
Not sure what you mean by 'unique id'.
When me and bsdlp refer to 'auth' we mean the auth system built into the actual game itself. It is vital to having the users auth associated with their profile, as the auth system is also used in-game.
That way we can uniquely link an FTWGL account to an UrbanTerror.info account.
Essentially what bsdlp is looking to doing is:
i think we would prefer not to have anything to do with the user's private auth key. Instead, what we really want is the ability to connect a user's urbanterror.info account to their ftwgl.com account. In addition, I believe validating a user's urban terror auth simply requires that we know their auth ID (int64 uid), and we would be able to confirm that by parsing logs when they connect or perhaps via rcon (would need to confirm rcon status prints auth id).
If urbanterror.info has no API (unlikely) and does not provide federated identity then i would prefer the solution to be the user providing their auth account name or uid (the ID# on this page) and we take it from there
I don't want move forward with this grander vision too much right now. I think the easy fix is add an field where a user can define this key.
Going forward we can identify if UrT has some way to support us validating this key and put together a plan to get this in place.
i dont think storing the private key is really going to be easier than storing the user's auth id or auth name. The goal is to verify that a client connecting to a match server is authed as the user we expect. As a server operator, we have access to the auth name and auth id, not the private key. We should be able to trust the server binary to correctly verify client auth and tell us about it.
Well then for our purposes now, storing just the users auth login would be sufficient.
to be clear, storing the auth username, right?
Yup, what is essentially their username on the UrT site.
I'll open a new issue to cover these.