Necessary Changes for Updating the Langman API
Get to know the necessary changes in the files for updating the Langman API.
Updating games API
With the JWT creation mechanism in hand, we must update the game API to use it correctly. We could add the decorator to require that the user is logged in, but then any user could still visit any other user’s games. One way to address that would be to query the database and see if the user is the right player for the game before allowing further access. This is problematic because it adds an additional and unnecessary database access. The better approach is to codify the access to that game within the token itself. Since a player can have multiple active games, their token should make claims for those game identifiers. Then, when the player accesses a particular game, the method will check whether the corresponding claim exists or not. The fact that the signature will ensure its validity is valid, and the token has not expired, which is checked by the decorator.
Updating the POST
method
The general pattern for the update is that everything at the root game route, that is, within the Games
resource, requires the token but not the claim on game_id
, and then it potentially returns the game_id
claim. The routes of the form /<game_id>
, meaning those within the OneGame
resource, require the token with the game_id
claim. This will prevent valid users from accessing other users’ games.
So, in Games.post
we add the @JWT.jwt_required()
decorator and change the part that checked whether the payload had the right information or not:
if not (games_api.payload and
'username' in games_api.payload and
'language' in games_api.payload):
games_api.abort(400, 'New game POST requires username and language')
lang = games_api.payload['language']
name = games_api.payload['username']
Get hands-on with 1400+ tech skills courses.