-
Notifications
You must be signed in to change notification settings - Fork 124
Authentication
- Users authenticate by supplying a string which has been posted to their accounts on either quakeworld.nu or badplace.eu
- Users can login to public servers
- Login status of all players shown in scoreboard
- Create account on badplace.eu, linked to quakeworld.nu account: follow link posted to quakeworld.nu account to complete process
- Create an authentication token, download & save in your config directory
-
/cl_username <username>
will load the authentication token into memory - In your QuakeWorld client, connect to a server supporting remote authentication
- If logins are mandatory, the process will start automatically during login
- If logins are optional, you can use
/authenticate
to initiate the process once connected - If you change
/cl_username
while logged in, that will be the same as calling/authenticate
-
/scr_scoreboard_login_names
will replace player's name with login when it is sent by server -
/scr_scoreboard_login_flagfile
maps player flags to graphics to be shown next to player's name when they are logged in -
/scr_scoreboard_login_indicator
will be shown next to a player's name when they are logged in (if flag not available) -
/scr_scoreboard_login_color
controls the color of a player's name when they are logged in
Process (old clients, authenticate via web browser at https://quakeworld.nu/)
- Login to quakeworld.nu (you will need to alt-tab back to this to complete the login)
- In your QuakeWorld client, connect to a server supporting remote authentication
- If logins are mandatory, you will be prompted for username as you connect
- If logins are optional,
/cmd login <username>
will start the process (you should see 'challenge stored') - Alt-tab back to web browser, refresh page and click on 'Messages' in top-right corner (it should have a star next to it)
- Click on the message from badplace.eu bot
- You should see an explanation of how to authenticate: typically copy & paste the
/cmd login-response ...
line into QuakeWorld client - The server will verify the response on the badplace.eu server, and log you in
Process (old clients, authenticate via web browser at https://badplace.eu/)
- Create account on badplace.eu, linked to quakeworld.nu account: follow link posted to quakeworld.nu account to complete process
- Login to badplace.eu (you will need to alt-tab back to this to complete the login)
- In your QuakeWorld client, connect to a server supporting remote authentication
- If logins are mandatory, you will be prompted for username as you connect
- If logins are optional,
/cmd login <username>
will start the process (you should see 'challenge stored') - Alt-tab back to web browser, click on 'Your Profile' in top-right and then click 'Challenges'
- The challenge from the current server should be visible - click 'copy' to copy the response to your clipboard
- Back in QuakeWorld client, paste the
/cmd challenge-response XXXXXXXX
command - The server will verify the response on the badplace.eu server, and log you in
Servers can't trust clients and clients can't trust servers, so instead authentication goes via a trusted third party server.
-
qw-client
claims to beusername
toqw-server
-
qw-server
asks3rd-party-server
to create a challenge/response pair, tied toqw-server
&username
-
3rd-party-server
informsqw-server
of the challenge-string only,qw-server
passes challenge toqw-client
- Player retrieves challenge response
-
qw-client
connects to3rd-party-server
using authkey issued tousername
and retrieves the challenge response - or:
player
logs in to website, & copies challenge response to clipboard
-
-
qw-client
sends the response back toqw-server
-
qw-server
verifies the response to the challenge with3rd-party-server
- if successful, player logged in asusername
Authentication keys are saved outside your config as configs are frequently shared. When game logs are uploaded, logins for each player are tied to the challenge/response pair.
- Compile mvdsv with libcurl support
- Contact meag and get a server api key
- Add server api key to
mvdsv.cfg
- (optional but encouraged) set
sv_forcenick 1
inmvdsv.cfg
(otherwise you can have someone logged in asmeag
and another person playing asmeag
, etc) - (optional) set
k_privategames_optional
inktx.cfg
, if you want players to be able to vote for/sv_login 1
- json file in
textures/scoreboard/
directory tells client images to load flags from - example flag images (warning: not a single graphic designer was disturbed in the making of this pk3)
- Authentication to QTV
- Supplying games where players logged in to stats.quakeworld.nu
- Ignoring based on username & unauthed players
- Currently using token exchange, would much prefer this to be client-side certificates - spent about 4 days on this but long story short, not yet. (badplace being .net on linux, packaging non-gpl openssl in static libcurl, osx would be different again) OpenSSL 3.0.0 will be GPL compliant, will look at it again then.
Authentication seems to come up semi-regularly, every time everyone argues their case and then nothing gets done. My personal preference would be OAuth to quakeworld.nu, but my understand is that the revamped site won't be available for some time. This isn't my ideal solution either but it is functional. If it's used but needs to be better at least we'll know what to fix next time, if it's not used at all we'll know authentication isn't really the solution to everyone's problems and we should work on something else.
No, you can use the old process above (start login, get challenge response from web browser, copy & paste into client). It's a bit more awkward but the end result is the same.
That would have been the case and may well be in the future (see first answer). Feel free to consider this a trial run of auth, if we throw it in the bin in 6 months I won't lose any sleep over it. You are at no point asked to enter your quakeworld.nu password on badplace.eu, and if you don't create a badplace account you can still use it through private messages on quakeworld.nu.
I didn't, most of the code for logins on the server was there already by VVD (based on a locally maintained list), and required logins to be either on or off. These changes essentially add the ability to login to servers even when in public mode, and through challenge/response rather than a password. Existing ban/allow logic remains the same. Server admins can also configure their servers to be semi-private (players must always authenticate but don't need an account) or fully private (still authenticate via website but will need to be in the server's local accounts list).
Absolutely not, if someone can login to server as player X it only proves they have access to player X's badplace.eu or quakeworld.nu account. It says nothing about the client they are using, and no checks are done on computer system or ip addresses.
Currently yes, I'm looking at what we can do with a f_authenticate client-only check to help clients authenticate on servers not linked to badplace.eu, and also to stop a dodgy server admin simply lying.
Given that clients & servers will always be able to essentially submit anything they like, I would imagine that there will always be 3-way checking of match results, or a tournament admin getting involved. We're some way away from that at the moment though.
By default, authentication is entirely optional on QW servers, and I imagine the vast majority of servers will stay public and would encourage them to do so. Logging in will be optional and probably only used in niche situations at the moment. It's important that we have some way of authenticating in order to have proper stats, ladder tournaments, tying race results to the correct people, etc. Making the login optional was the best way I could think of doing this.
It seems a common request that comes up, especially when malicious users deliberately fakenick to ruin other/new player's experience.
Future development on badplace to help with tournament reporting, reboot of the ladder tournament, better stats, better race record tracking, etc etc
Coming soon.