Cadillac at 01:05, 23 August 2021

2021-08-23T01:05:59Z

← Older revision		Revision as of 20:05, 22 August 2021
Line 81:		Line 81:

	The server would print the message to the client.		The server would print the message to the client.

			[[Category:Development]]

Epsy: Added a clause on how the server should handle refreshes

2012-04-02T00:07:28Z

Added a clause on how the server should handle refreshes

← Older revision		Revision as of 19:07, 1 April 2012
Line 67:		Line 67:

	/armaauth/0.1/?query=refresh&prefer=tournaments/ladle/servers/myserver&users=john&users=may&users=jack&time=1333333333		/armaauth/0.1/?query=refresh&prefer=tournaments/ladle/servers/myserver&users=john&users=may&users=jack&time=1333333333

			On the server end, the server should change the players' GIDs accordingly, elevating players where relevant.

			The server could initiate such a refresh at the command of a server admin, or before every new warmup(side note: the warmup system allows for multiple matches to be played simultaneously). All priviledges could also be first revoked at first on such an occasion, for instance for resetting temporary captains.

	==Web Authentication==		==Web Authentication==

Epsy: Created

2012-04-01T23:50:07Z

Created

New page

==Things that were bad==

* "Group" authentication (subdirectories):
** Terrible usability: One must specifically authenticate to the subgroup for it to work, or the authority has to do arbitrary guesswork.
*** ie. <code>/login user@authority/directory</code>
*** As for authority guesswork, they can currently guess from the server's IP. The remote port data at this point is irrelevant, and the IP can be hidden by a proxy authority.
** Inability to express multiple groups
* Web Auth
** Needs DB access on the consumer end. Could be avoided
** Disabled by default in the reference implementations. Next to no adoption on the authority end.
** Only interfaces with websites specifically designed for it (read: none)

==Improvements that can be conducted==

==="Group" authentication===

====Group preference====

The server could take a list of preferred authorities/groups and forward it to the authorities. The setting would be optional.

PREFER_AUTHORITIES authority...
PREFER_AUTHORITIES ct/senior x/ctseniors x/ctoverseniors

When authentifying someone, the server can send the applicable authorities(same host) with the check requestas a <code>prefer</code> parameter. For instance, when querying <code>x.authentication.armagetronad.net</code>:

/armaauth/0.1/?query=check&method=md5user=john&hash=abcd&salt=efgh&prefer=ctseniors&prefer=ctoverseniors

The authority respond with the first group in the list that the user is allowed into.

Additionally, the server can provide a setting that would automatically provide group preferences based on "best" AUTHORITY_LEVEL settings. Similar to <code>/listadmins</code>, this poses a moderate security threat, advertising what authorities grant high access, so this should be disabled by default.

PREFER_AUTHORITIES_AUTO 1
AUTHORITY_LEVEL ct/senior 2
AUTHORITY_LEVEL x/ctsenior 2
AUTHORITY_LEVEL x/ctoversenior 1

/armaauth/0.1/?query=check&method=md5&user=johnhash=abcd&salt=efgh&prefer=ctoverseniors&prefer=ctseniors

An authority could "abuse" this system to voluntarily return different authorities than those requested. This could be used to create server tokens. For example:

PREFER_AUTHORITIES x/tournaments/ladle/servers/myserver
AUTHORITY_LEVEL x/tournaments/players/playing 8
AUTHORITY_LEVEL x/tournaments/players/captain 7

If it were the time for the finals, the authority could identify "myserver" as referring to the server used in the finals, and identify each player as playing or captain or neither, at login time.

===Updating preferences===

If the preferences have changed while people are in the server, it might be in the best interest of everyone to update the current players' status. Of course, everyone could log out and back in, but that's very impractical.

I suggest instead a mass update mechanism, by sending a bulk query to each authority. For instance:

/armaauth/0.1/?query=refresh&prefer=tournaments/ladle/servers/myserver&users=john&users=may&users=jack

The server may merge all queries to one per authentication host. The authority responds:

USER john@x/tournaments/players/playing
USER may@x/tournaments/players/captain
USER jack@x/tournaments/players

In case a user is not found, the authority should replace the corresponding USER line with:

USER_NOT_FOUND username

This system can be otherwise used to check player GIDs. If it matters, a client should be able to override the server time like such:

/armaauth/0.1/?query=refresh&prefer=tournaments/ladle/servers/myserver&users=john&users=may&users=jack&time=1333333333

==Web Authentication==

===OpenID===

OpenID would standardize the process into something that has software already available for it. This would result in making it an easier process to convert software to consume OpenIDs. It would be signaled as "openid" in the METHODS response. More info TBD.

==Actually use MESSAGE==

The server would print the message to the client.

Authentication Groups Draft - Revision history

Cadillac at 01:05, 23 August 2021

Epsy: Added a clause on how the server should handle refreshes

Epsy: Created