Introduce discord whitelisting for authentication#174
Conversation
|
Awesome! Is it possible to further iterate on this to allow oauth2 discord log-in? Current implementation is a bit user-hostile due to how much command line tier fuckery you need to do, my worry is it's a big turn off for anyone new who isn't being walked through the process by hand. |
I'm not entirely sure how to make the setup any more user friendly than it is at the moment. Although if server owners are putting security first at the top of their list, whitelist setup shouldn't be any more complicated than setting up the bridgebot with its token. It would be best if instructions were documented in the README.md to explain the bot setup and its parameters. The implementation is only around a week old and we haven't explored oauth2 log-in. Also wanted to add on to this: Currently exploring if this system would behave any differently for a DRO server. |
Crystalwarrior
left a comment
Crystalwarrior
left a comment
There was a problem hiding this comment.
Do you have to do /whitelist every time you connect to the server?
| def ooc_cmd_whitelistself(client, arg): | ||
| """ | ||
| Whitelist other clients if you are multiclienting | ||
| Usage: /whitelistself | ||
| """ | ||
| if not (client.server.config["whitelist"]): | ||
| raise ArgumentError("Whitelist is not enabled on this server!") | ||
| if client.is_wlisted == False: | ||
| raise ArgumentError("You cannot whitelist other clients if you aren't whitelisted!") | ||
| clientcount = 0 | ||
| for targetc in client.server.client_manager.clients: | ||
| if client.ipid == targetc.ipid: | ||
| if targetc.is_wlisted == True: | ||
| continue | ||
| targetc.is_wlisted = True | ||
| targetc.discord_name = client.discord_name | ||
| targetc.send_ooc("You have been whitelisted by the parent client!") | ||
| clientcount += 1 | ||
| if clientcount == 0: | ||
| raise ArgumentError("No other unwhitelisted clients with the same IP were found!") | ||
| else: | ||
| client.send_ooc(f"You have whitelisted {clientcount} other clients!") |
There was a problem hiding this comment.
I feel this should automatically apply to the first /whitelist command so all your connections get treated as whitelisted. Currently, /whitelistself command is impossible to know about normally without knowing a guy to tell you it exists.
Additionally, /whitelistself lacks a docs/Commands.md entry
| f"No such command or submodule ({arg}) has been found in the help docs." | ||
| ) | ||
|
|
||
| def ooc_cmd_whitelist(client, arg): |
There was a problem hiding this comment.
This and /whitelistself should probably be merged.
Additionally, /whitelist lacks a docs/Commands.md entry.
There was a problem hiding this comment.
I am a little reluctant to try merging these two as it would require us to remember all clients with the same IPID in between the request and the discord interaction to approve it. (Might have to consider edge cases where clients are removed during the authentication process and the server tries whitelisting nonexistent clients)
/whitelistself is based on a tsuserverDR command known as /gmself which allows users to whitelist from an authenticated client without interaction from discord.
There was a problem hiding this comment.
btw KFO has a /gmself equivalent with /gm *, I should probably make it a default alias
Co-authored-by: Crystalwarrior <Varsash@Gmail.com>
Co-authored-by: Crystalwarrior <Varsash@Gmail.com>
|
Closing as this doesn't meet discord oauth requirement. Would like to revisit when we manage to brainstorm a proper whitelist persistence solution. |
2 participants
A semi-complete implementation that allows server owners to require users to identify themselves through discord. This is an effective anti-raid measure in practice but would need to be further iterated on to perfect it.
I would advise testing this before considering any merge as the code comes from other tsuserver builds.
Details
When whitelisting is enabled from the config, all clients that connect to the server cannot send packets corresponding to IC/OOC/evidence/modcall with the exception of the /whitelist command that can be sent in OOC.
They must specify their exact discord account username to identify who is authenticating the client on discord. Upon sending the command, it generates a "player ID" they will use for the discord interaction. There are optional webhook parameters to enable logging of whitelist requests should it make easier for staff to identify bad actors.
When the whitelist command from discord is sent with the correct player ID, it will check for three conditions:
If the client targeted is already whitelisted,
If the requested username matches the one who sent the command,
If the client with the PID exists in the server,
If done correctly, the user should be able to authenticate their client and be able to interact with the server normally. Anonymity is traded out for this system so discord usernames appear when retrieving area information (which can be easily modified to only be shown in modview). Additionally, I added a delay to the whitelist webhook using threading to avoid spam.
There's still a lot more to flesh out. The /whitelistself command to authenticate multiclients is still a recent addition. Some users we've observed are asking for us to have the server remember them on IP. (Possible, but some users have their IPs changing constantly so there's no perfect fit-all solution. Doing it by HDID is bad in practice because it can be spoofed by bad actors)