Feature #348

Authentication system

Added by Jacker over 3 years ago. Updated about 2 years ago.

Status:New% Done:

0%

Priority:High
Assignee:Jacker
Category:General
Target version:2.77
OS: Arch:

Description

We should add an authentication system to legacy, which would add the support for clients to be able to authenticate against our to be created authentication server. Game server would be able either accept only authenticated players or just skip the authentication allowing all players to join.

Implementing this on the client & server code would allow all the existing mods to have support for an authentication system.

The auth system would make kicking/banning and identifying players more effective, which would be a welcome addition for both the public and clan play.

Associated revisions

Revision ac4e3c5b
Added by Spyhawk about 1 month ago

client: removed FEATURE_LIVEAUTH, refs #348

History

#1 Updated by IR4T4 over 3 years ago

  • Category set to General

#2 Updated by IR4T4 over 3 years ago

  • Target version changed from 2.71rc3 to 2.71rc4

#3 Updated by Jacker over 3 years ago

  • Target version changed from 2.71rc4 to 2.77

#4 Updated by Jacker about 3 years ago

We should include an in game Reporting system that people can report cheaters IN GAME like in CS:GO. That way suspicious players will get picked out much faster. Would not require much actually, just an custom .menu and a post request from the engine curl component.

#5 Updated by Dragonji about 3 years ago

That will probably add a lot of unnecessary work to you guys. There surely will be a lot of false reports from frustrated players with low skills.

#6 Updated by Jacker about 3 years ago

If ETL at some point really takes of the ground I hope that we will not have a shortage of helping hands..

#7 Updated by Spyhawk about 3 years ago

Not sure about the way you’re choosing to implement the auth/ban system, but:
- make it easy for the admins of the server to review the complains - reviewing them should be primarily their job, not the job of et:l team.
- also send the ID of the complainer. People complaining without real justification should face the consequences.

(although I’m sure you’ve thought about this already)

#8 Updated by Jacker about 3 years ago

Spyhawk wrote:

Not sure about the way you’re choosing to implement the auth/ban system, but:
- make it easy for the admins of the server to review the complains,
- also send the ID of the complainer. People complaining without real justification should face the consequences.

This is not game server based (that can be made with lua if someone so chooses). This is meant for players to send an message to us (read legacy team). Because we have the auth database aka → we can tag/ban players.

#9 Updated by Spyhawk about 3 years ago

Jacker wrote:

This is not game server based (that can be made with lua if someone so chooses). This is meant for players to send an message to us (read legacy team). Because we have the auth database aka → we can tag/ban players.

Yes, I’ve understood this. What I mean is that if et:l project is successful (and it will ), the banning/tagging workload will increase proportionally to the number of et:l server. Unless the legacy team increases also proportionally, the involved workload isn’t sustainable on the long term.

If this tag/ban work can’t be automated, the only way to make this working efficiently would be to externalize it. In a nutshell, make the various server admins do the grunt but necessary work, while the legacy team will treat all special requests only.

Here’s how this could be handled.

The admins of server X get a special panel on the auth server. When a player on server X file a complain, the request is sent on the auth server, in the server admin panel X. Admins of X choose to ban the players or not, depending on the proof they got (demo, screenshot, whatever). Legacy team can in any time do the job, or reverse the decision of admins of server X. Admins of server Y get a similar panel on the auth server, and treat requests generated from their server.

Implementation would be surely more complex than the above (ie, banning/tagging could be partially made automatically, with x request from x different players, etc), but you get the underlying idea: to make it efficient, distribute the workload.

#10 Updated by Dragonji about 3 years ago

Spyhawk wrote:

Here’s how this could be handled.

The admins of server X get a special panel on the auth server. When a player on server X file a complain, the request is sent on the auth server, in the server admin panel X. Admins of X choose to ban the players or not, depending on the proof they got (demo, screenshot, whatever). Legacy team can in any time do the job, or reverse the decision of admins of server X. Admins of server Y get a similar panel on the auth server, and treat requests generated from their server.

I like the idea! However, in my opinion admins should be able to send a complaint further to ET:L team which might decide then not to only ban a player on a specific server but globally.

Spyhawk wrote:

Legacy team can in any time (...) reverse the decision of admins of server X.

Legacy team shouldn’t have power to remove specific local bans, it should be up to the server owners only (not talking about global bans which should only be handled by ET:L team IMO).

#11 Updated by Spyhawk about 3 years ago

Dragonji wrote:

I like the idea! However, in my opinion admins should be able to send a complaint further to ET:L team which might decide then not to only ban a player on a specific server but globally.

Legacy team shouldn’t have power to remove specific local bans, it should be up to the server owners only (not talking about global bans which should only be handled by ET:L team IMO).

As I understand it, the Auth server is only about global bans. Local bans will be handled as they currently are (shrubbot, lua, ..). And yes, I suggest that the admins enable the global bans themselves, but they should upload a proof to the server at the same time. A banned player that appeals his ban will see his request handled by the legacy team, and if no proof was given (or if it the given proof is disputable), the player will simply get unbanned.

As a side note, I’ve seen community websites run by companies that use the same principle to check users content. Instead of checking by themselves profile pictures, they ask random users to have a look (optionally) and do the work. I believe admins that see cheaters destroying their beloved server would gratefully help to globally ban them

#12 Updated by TheDushan about 2 years ago

No!

This is not just about admin authentication or global ban.
With this you can provide and do more things, like I tried with OpenWolf.
In my old source I had complete working HTTP crash system with bug reporting UI.

For login you can do something like this.

int Net_HTTP_Init() {
http.multi_handle = curl_multi_init();

if ( http.multi_handle == NULL ) {
return 0;
}

http_usernameandpassword = Cvar_Get( "usernameandpassword", "username:password", CVAR_ARCHIVE );
http_bugauth = Cvar_Get( "http_bugauth", "username:password", CVAR_ARCHIVE );
http.headers = curl_slist_append( http.headers, "Accept: application/openwolf" );
return -1;
}

this is basic what I had for client

#if defined (USE_HTTP)
Cmd_AddCommand ("login", CL_Login_f, "^1Login to URL.");
Cmd_AddCommand ("highscore", CL_Highscore_f, "^1Gets highscores results from the website.");
Cmd_AddCommand ("forgotpassword", CL_ForgotPassword_f, "^1Send forgot password request to URL.");
Cmd_AddCommand ("getaccount", CL_GetAccount_f, "^1Get account from URL.");
Cmd_AddCommand ("globalhighscores", CL_GlobalHighScores_f, "^1Get highscores from URL.");
#endif

for login system on webpage

static void CL_Login_f( void ) {
if ( Cmd_Argc() != 3) {
Com_Printf( "usage: login user password\n");
return;
}

HTTP_PostUrl( va("http://%s/user/login", AUTHORIZE_SERVER_NAME), CL_Login_response, 0, "user[login]=%s&user[password]=%s&version=%d", Cmd_Argv(1), Cmd_Argv(2), 31 );
}

#13 Updated by Jacker about 2 years ago

I had the auth system already done and the serverside is still online, but i never committed the code to the master as we agreed that we would work with the etlive group and combine the auth systems. That never took off tho, and i have no idea of the live projects status.

The etlive implementation also used curl:s http requests and had a backend with www technology.

The implementation which i did was done with the existing plain udp sockets / string payloads so it was very lightweight, and it did/does have encryption with aes256. The backend is a simple udp sockets server (multithreaded tho) which actually is the one handling the current udpate and motd messages for the legacy clients and servers.

#14 Updated by Jacker about 2 years ago

Auth ofc will open a lot of doors for us (if we ever drop it in) as we can do a lobby systems, complaint systems and so fort.. Its just a matter of making them work.

Also available in: Atom PDF