* Installing b2sdk for b2 support
* Added Duplicity PPA so the most recent version is used
* Implemented list_target_files for b2
* Implemented b2 in frontend
* removed python2 boto package
* add user interface for managing 2fa
* update user schema with 2fa columns
* implement two factor check during login
* Use pyotp for validating TOTP codes
* also implements resynchronisation support via `pyotp`'s `valid_window option
* Update API route naming, update setup page
* Rename /two-factor-auth/ => /2fa/
* Nest totp routes under /2fa/totp/
* Update ids and methods in panel to allow for different setup types
* Autofocus otp input when logging in, update layout
* Extract TOTPStrategy class to totp.py
* this decouples `TOTP` validation and storage logic from `auth` and moves it to `totp`
* reduce `pyotp.validate#valid_window` from `2` to `1`
* Update OpenApi docs, rename /2fa/ => /mfa/
* Decouple totp from users table by moving to totp_credentials table
* this allows implementation of other mfa schemes in the future (webauthn)
* also makes key management easier and enforces one totp credentials per user on db-level
* Add sqlite migration
* Rename internal validate_two_factor_secret => validate_two_factor_secret
* conn.close() if mru_token update can't .commit()
* Address review feedback, thanks @hija
* Use hmac.compare_digest() to compare mru_token
* Safeguard against empty mru_token column
* hmac.compare_digest() expects arguments of type string, make sure we don't pass None
* Currently, this cannot happen but we might not want to store `mru_token` during setup
* Do not log failed login attempts for MissingToken errors
* Due to the way that the /login UI works, this persists at least one failed login each time a user logs into the admin panel. This in turn triggers fail2ban at some point.
* Add TOTP secret to user_key hash
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`
* Typo
* Reorganize the MFA backend methods
* Reorganize MFA front-end and add label column
* Fix handling of bad input when enabling mfa
* Update openAPI docs
* Remove unique key constraint on foreign key user_id in mfa table
* Don't expose mru_token and secret for enabled mfas over HTTP
* Only update mru_token for matched mfa row
* Exclude mru_token in user key hash
* Rename tools/mail.py to management/cli.py
* Add MFA list/disable to the management CLI so admins can restore access if MFA device is lost
Co-authored-by: Joshua Tauberer <jt@occams.info>
* conf/nginx-primaryonly.conf: Use tabs instead of spaces
* management/web_update.py: Includes the tabs so they display with the correct indentation when added to the local.conf
Co-authored-by: 0pis <0pis>
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`
* Due to the way that the /login UI works, this persists at least one failed login each time a user logs into the admin panel. This in turn triggers fail2ban at some point.
* hmac.compare_digest() expects arguments of type string, make sure we don't pass None
* Currently, this cannot happen but we might not want to store `mru_token` during setup
* this allows implementation of other mfa schemes in the future (webauthn)
* also makes key management easier and enforces one totp credentials per user on db-level
* Only spawn a thread pool when strictly needed
For --check-primary-hostname, the pool is not used.
When exiting, the other processes are left alive and will hang.
* Acquire pools with the 'with' statement
This will make it so that the HSTS header is sent regardless of the request status code (until this point it would only be sent if "the response code equals 200, 201, 206, 301, 302, 303, 307, or 308." - according to thttp://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header)
These subdomains/records are for automatic configuration of mail clients, but if there are no user accounts on a domain, there is no need to publish a DNS record, provision a TLS certificate, or create an nginx server config block.
When the management commands fail, they can print something to the standard error output.
The administrator would never notice, because it wouldn't be send to him with the usual emails.
Fixes#1763
* Create the mta_sts A/AAAA records even if there is no valid TLS certificate because we can't get a TLS certificate if we don't set up the domains.
* Make the policy id in the TXT record stable by using a hash of the policy file so that the DNS record doesn't change every day, which means no nightly notification and also it allows for longer caching by sending MTAs.
Folks didn't want certificates exposing all of the domains hosted by the server (although this can already be found on the internet).
Additionally, if one domain fails (usually because of a misconfiguration), it would be nice if not everything fails. So grouping them helps with that.
Fixes#690.
