This change introduces a new "Admin" page to boardwalkd, along with some basic user management capabilities. The purpose of this update is to provide some way to at least disable users who have previously logged in, and to pave the way for other features that depend upon having an admin panel (such as service account support).
Some background: boardwalkd has a way to authenticate users, currently only with Google Oauth2. It's very simple; it just validates that user has a Google account, reads their email address, and then allows the user full access to the boardwalkd UI and API. They are issued a session token for the duration as configured by server options. The server doesn't re-authenticate the user with Google until the session token is invalidated. Before this change here, there was no way to disable a user before their session expired.
Items included with this change
There is a new User state model
Users who log in are now stored in the statefile
Users models have a set of possible "roles", which are used to determine what pages can be visited. Presently there is just a "default" role, which does nothing, and an "admin" role, which allows access to admin routes
There is now an Admin page for managing user roles and enabling/disabling, along with some related HTMX templates for controls
The server now has an --owner option, which is used to set a user who will always be admin. The intention of this is described in the help text for the option
Known issues and design notes:
The server statefile may need to be recreated when this update is deployed
Users will have to delete their boardwalk_user cookies to break their active sessions, because they are added to the statefile when they log in. If they don't exist in the statefile, they will be denied access
Email addresses are the only way that users are uniquely identified. When user email addresses change, boardwalkd will not see the user as the same user. This is done for simplicity and with the assumption that email addresses will rarely change in the environments where boardwalk is deployed
How was this tested?
tested locally with the development server along with the test Boardwalkd.py. Testing included some manual confirmation that malformed requests will be rejected.
Checklist
[x] Have you updated the VERSION file (if applicable)?
What and why?
Fixes #18
This change introduces a new "Admin" page to boardwalkd, along with some basic user management capabilities. The purpose of this update is to provide some way to at least disable users who have previously logged in, and to pave the way for other features that depend upon having an admin panel (such as service account support).
Some background: boardwalkd has a way to authenticate users, currently only with Google Oauth2. It's very simple; it just validates that user has a Google account, reads their email address, and then allows the user full access to the boardwalkd UI and API. They are issued a session token for the duration as configured by server options. The server doesn't re-authenticate the user with Google until the session token is invalidated. Before this change here, there was no way to disable a user before their session expired.
Items included with this change
--owneroption, which is used to set a user who will always be admin. The intention of this is described in the help text for the optionKnown issues and design notes:
How was this tested?
tested locally with the development server along with the test Boardwalkd.py. Testing included some manual confirmation that malformed requests will be rejected.
Checklist