Skip to content
meag edited this page Oct 10, 2020 · 1 revision

Web-based authentication changes (in test)

Overview

  • 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

Process

(ezQuake 3.6-alpha3+, possibly 3.3 in future)

  • 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

Explanation

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 be username to qw-server
  • qw-server asks 3rd-party-server to create a challenge/response pair, tied to qw-server & username
  • 3rd-party-server informs qw-server of the challenge-string only, qw-server passes challenge to qw-client
  • Player retrieves challenge response
    • qw-client connects to 3rd-party-server using authkey issued to username and retrieves the challenge response
    • or: player logs in to website, & copies challenge response to clipboard
  • qw-client sends the response back to qw-server
  • qw-server verifies the response to the challenge with 3rd-party-server - if successful, player logged in as username

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.

Server configuration

  • 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 in mvdsv.cfg (otherwise you can have someone logged in as meag and another person playing as meag, etc)
  • (optional) set k_privategames_optional in ktx.cfg, if you want players to be able to vote for /sv_login 1

Client configuration

  • 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)

Things to improve/next steps

  • 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.

Questions

Why doesn't it use (method x y z), it's better

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.

Do I have to use new client?

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.

Why is it authenticating to badplace.eu and not quakeworld.nu?

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.

Why have you added logins to mvdsv?

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).

Does this prove that the person isn't using a hacked client

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.

Aren't clients taking it on faith that the server is telling the truth

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.

I don't want to authenticate, you are ruining QuakeWorld

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.

What's the point?

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

Can I link my account to Discord/Twitch/etc

Coming soon.