Previously, I had changed the default value to "", to force
users to set the SECRET_KEY value (the app refuses to start
if SECRET_KEY is empty).
The problem with that is, out of the box, with the default
configuration, the tests also don't run and complain about the
empty SECRET_KEY.
So, a compromise: revert back to the default value "---".
At runtime, if SECRET_KEY has the default value, show a warning
at the top of every page.
The initial implementation was just calling signal-cli directly
using `subprocess.run`.
Going with DBus makes it easier to shield signal-cli from the
rest of the system. It also makes sure the signal-cli daemon is
running in the background and receiving messages. This is important
when a recipient does the "Reset secure connection" from the app. We
must receive their new keys, otherwise our future messages will
appear as "bad encrypted message" for them.
* Add HTTP header authentiation backend/middleware
* Add docs for remote header auth
* Improve docs on external auth
* Add warning for unknown REMOTE_USER_HEADER_TYPE
* Move active check for header auth to middleware
Add extra header type sanity check to the backend
* Add test cases for remote header login
* Improve header-based authentication
- remove the 'ID' mode
- add CustomHeaderBackend to AUTHENTICATION_BACKENDS conditionally
- rewrite CustomHeaderBackend and CustomHeaderMiddleware to
use less inherited code
- add more test cases
Co-authored-by: Pēteris Caune <[email protected]>