Right now, we check the identity of a user based on their username instead of their userid. This is kinda bad: if a user leaves, then a new user can sign up and claim the old username, and all privileges associated with that username. To fix this, we want to authenticate based on userid instead of username.

You will probably need to edit the authenticating decorators in app/app.py, and the User model in app/models.py

• See https://developers.mattermost.com/integrate/slash-commands/ for slash-command documentation
• You will probably need to convert a username to userid to make the /authorize command human-friendly. You can use the Mattermost API for that
• You will need to add a userid column to the database

private quotes

"

To open the door without a key, you need to use /door open on Mattermost. Unfortunately, the Mattermost app is quite slow, so this takes ~30 seconds for me. It would be nice if this were faster, for example by using https://github.com/mwarning/trigger. To be able to use that app, we need an HTTP API to open/close the door

Flow:

1. User is authorized on Mattermost by the board
2. User uses /door links and receives the links of the open and close endpoint in an ephemeral message, with their personal token prefilled
3. User copies these URL's into the app, then uses the app to open/close the door

Steps to get this done:

• add a user_token field per user, make sure the migration and adding of new users fills these with secure random values
• add a /door links subcommand
• add authorized open and close endpoints
• write some documentation in the Zeus wiki

Some notes:

Using this API would only be allowed after the user does an action themselves (for example, tapping a button in an app). The user needs to be aware that they opened/closed the door. Building a system with this that would allow other persons (even if authorized) to open the door with your token would be strictly prohibited (talk to the board/sysadmins if you want to build such an integration, we'll help you get this done if it's a good idea).

Currently, there are 2 mattermost channels in which door updates appear:

• ~kelder: here, messages like door was open, redfast00 tried to lock door via the API get posted
• ~verbose-mattermore: here, messages like "open" command from Mattermost handled, The door is now open and logging messages get posted

This approach was easy to implement (it's stateless, so we don't have to keep any state between requests in the mattermore backend), but is not that friendly for humans:

• if you see a message in ~kelder and want to know if the action succeeded, you have to look in ~verbose-mattermore
• it's hard to see when the door was manually opened: you have to look in ~verbose-mattermore and then discard all updates that are because of users electronically opening the door

Just changing the door was open, redfast00 tried to lock door into door was open, redfast00 locked the door is a bad approach: locking the door can fail (for example, if the door is misaligned and the dead bolt hits the strike plate), this would not be correct.

A possible approach is to use a state machine and a background task, but I'll leave it up to you on how you want to solve it.

Convenient issue to test if this already works...