The /admin/munin routes used the same Authorization: header logic as the other API routes, but they are browsed directly in the browser because they are handled as static pages or as a proxy to a CGI script.
This required users to enter their email username/password for HTTP basic authentication in the standard browser auth prompt, which wasn't ideal (and may leak the password in browser storage). It also stopped working when MFA was enabled for user accounts.
A token is now set in a cookie when visiting /admin/munin which is then checked in the routes that proxy the Munin pages. The cookie's lifetime is kept limited to limit the opportunity for any unknown CSRF attacks via the Munin CGI script.
Since the session cache clears keys after a period of time, this fixes#1821.
Based on https://github.com/mail-in-a-box/mailinabox/pull/2012, and so:
Co-Authored-By: NewbieOrange <NewbieOrange@users.noreply.github.com>
Also fixes#2029 by not revealing through the login failure error message whether a user exists or not.
* Rename the 'master' API key to be called the 'system' API key
* Generate the key using the Python secrets module which is meant for this
* Remove some debugging helper code which will be obsoleted by the upcoming changes for session keys
thanks @downtownallday
* this invalidates all user_keys after TOTP status is changed for user
* after changing TOTP state, a login is required
* due to the forced login, we can't and don't need to store the code used for setup in `mru_code`
Intended to be the simplest auth possible: every time the service
starts, a random key is written to `/var/lib/mailinabox/api.key`. In
order to authenticate to the service, the client must pass the contents
of `api.key` in an HTTP basic auth header. In this way, users who do not
have read access to that file are not able to communicate with the
service.
