KtorZ
commented
8 years ago What about having only one token, the one which give a user the access to request restricted endpoints. If I may reformulate your first table like this:
| Actions | Requires |
|---|---|
| Join a public game as User | Authenticated User |
| Join a private game as User | Authenticated User + Game Password |
| Play a game as User | Authenticated User + User is in Game |
| Read a public game | - |
| Read a private game | Authenticated User + Game Password |
The Authenticated User traduces a session, and we thus have to handle it with a token so that the session management is under the client responsibility.
The Game Password is part of the Game object, and could just be transmitted as a request parameter. No need for a token here.
The "User is in Game" assertion is also part of the Game object. That object is persisted in the database, and is changed on a join request. There is no notion of session here because that action isn't related to the client and it cannot expires. Once a player has joined, the Game object behave differently and accordingly forever; there's no way back. That's why we don't need a token.
However, having no token for a game means to check in the database each time a player is making a move. A game token is a shortcut to prevent the server from reaching the db on every request. For spectator, as we'll only need to check in the db for the join, we can simply stick with the game password.
Thus, we can rather end up with something like this:
| Endpoint | Requires | Returns |
|---|---|---|
| Join a public game as User | userToken | playerToken |
| Join a private game as User | userToken + game password | playerToken |
| Play a game as User | playerToken | Game + Board updated |
| Read a public game | - | Game + Board |
| Read a private game | game password | Game + Board |
Soreine
We were thinking about using game tokens and user tokens:
We can see that there are 2 types of
gameToken. OnegameTokenfor reading a game. The othergameTokenfor writing (playing) to a game as a certain User.We should differentiate between a
playerTokenand aspectatorToken. The spectating mode andspectatorTokencan be implemented later. It's important keep the nameplayerTokenbecause it is unique for each player+game combination.A
playerTokenthus contains thegameIdand auserId, it acts both as an authentication token and an authorization token. AspectatorTokenwould contain only the gameId.