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.
With the previous 10 minutes / minute limit we were still hitting
Telegram API rate limit (the 429, "Too Many Requests" response)
from time to time.
Therefore, tighten the limit a bit on our side.
The PhoneNumberForm is used in "Add SMS" and "Add Phone Call" pages.
The PhoneUpDownForm is a subclass of PhoneNumberForm and
adds "up" and "down" boolean fields. It is used in "Add Signal"
and "Add WhatsApp" pages.
* 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 <cuu508@gmail.com>
User handle is used in a username-less authentication, to map a
credential received from browser with an user account in the
database. Since we only use security keys as a second factor,
the user handle is not of much use to us.
The user handle:
- must not be blank,
- must not be a constant value,
- must not contain personally identifiable information.
So we use random bytes, and don't store them on our end.
Planning to use it for sensitive operations (add/remove security keys),
change email, change password, close account.
The decorator sends a six-digit confirmation code to user's email
and renders a form for entering it back. If the user enters the
correct code, the decorators sets a sudo=active marker in
user's session, valid for 30 minutes.
When sending email using Django's default email
backend (SMTP), and if there is a network issue, the backend
can throw SMTPServerDisconnected.
This commit adds a retry logic which retries sending the
email two times when SMTPServerDisconnected is thrown.
Normally, when a webhook call fails (timeout, connection
error, non-2xx response), the HTTP request is retried up to two
times (so up to 3 times total). This is useful when sending
actual notifications, in case the webhook target has a temporary
glitch.
When interactively testing a webhook integration
("Send Test Notification" in the
"Integrations" page), we would prefer to see any errors ASAP
on the screen instead of retrying and so possibly swallowing them.
One specific use case is webhook targets that take long time to
generate a response. "Send Test Notification" is synchronous,
meaning that the user could be stuck for
5 x 3 = 15 seconds waiting for the test HTTP request to time out
three times.
