Stkaddons Client Authentication
This document is only a proposal at this time. As such, it is a work-in-progress. Other relevant pages:
The following is a summary of all currently implemented requests and possible responses:
Done - Initial Log-In
In order to connect a game client to the add-on server, the game should request
where the second option is for temporary connections with non-registered users.
Response XML would look something like the following:
<?xml version="1.0"?> <connection id="36db7f85-613b-4214-847d-a827c0052204" user="4" registered="true" />
The Client-ID Concept
Server-side, a "client-id" will be generated. This will be a pseudo-random string, at least 12 characters long to ensure some randomness and non-guess-ability. This id will be returned by the connection script in the form of a simple XML document.
On the server, a database table exists (client_sessions) with the following schema:
|User id from the user table, or 0 if an unregistered user||Temporary nickname, or NULL if a registered user||client-id||Timestamp of the last request by this client|
Every time the game makes a request, it will send either the user id or the nickname, with the client-id. The game will receive a new client-id after each request, and the server will update the appropriate entry in the table.
By re-generating client ID's after each request, it makes the system more secure. Transmitting a password back and forth repetitively is incredibly insecure. By only transmitting a password on the first connection, the likelihood of interception is minimized. A persistent client-id would essentially become the same as a password, which could be intercepted and used. However, if the client-id is only valid once, or is time limited in some way or other, this is less of an issue.
Registered and Unregistered Users
Non-registered users will not have the same permissions on the addon-server.
|Rate an Add-On||Yes||No|
|Register more than one client per user||Yes||No|
Done - Voting for an Add-On
The server request might look something like:
The server response would be:
<?xml version="1.0"?> <vote id="794bb7fe-01fc-452f-9868-4ca171725600" value="2.35" addon-id="snow-mountain" success="1" />
where 'id' is a new client-id, 'value' is the add-on's new rating value, 'success' is a boolean to check if the vote registered. On error, the response would be a HTTP 403/Forbidden error.
The widget used to vote in-game might look like this:
A cron job will run hourly to purge inactive client-id's - for unregistered users, this would be after two hours. For registered users, this would be after 2 months. Registered users could have multiple client-id's registered under the same name. Unregistered users using a nickname can only have one client per nickname (this ensures no duplicate nicknames, as well as freeing up temporary nicknames.) People who want persistent nicknames can easily register on STKAddons. Once a registered user's client ID expires, they simply need to log-in again. Their nickname is still registered.