We want to persist the session during development. Otherwise the session
is reset everytime the server is restart. This behavior make developing
bot a front and back feature a nigthmare, we spend our time login again
and again.
Shamelessly copy/pasted from @lunika 's work
suitenumerique/docs@007854a
In this commit, we stop creating /users and /allows in dimail
for our dbs to be in sync. People with stop impersonating users
in dimail and will create mailboxes using its own credentials.
Bump the lib to the latest version:
- update the post_get_or_create_user method signature
- allow silent login for OIDC (will require frontend implementation)
The secondary email address is no longer required for all creation
processes and we should not force the user to provide and store an
insecure email address.
Override save is a better way to auto generate api_key if
it is not set.
Default with random secret generate a new migration each time we
run `make makemigrations`.
Create new model to allow access of some API
endpoints with API Key authentification.
Scopes will allow to define permission access on those
endpoints.
The new DRF version (3.16.0) adds a check on unique together and needs
more fields to be loaded. To prevent an extra query, we select the owner
value in the DB query.
Add flag to indicate whether the organization is active.
Prepare organizations provisioning. The organization
will be created with this flag set to False and will
become active when the first user is associated with it.
Management command "setup_dimail_db" called dimail directly, thus
creating duplicated code. It now calls "create_domain" and "create_allow"
methods from DimailAPIClient (create_user is left unchanged to create
special users such as dimail admin or people)
For readability, we move the code block from the `ready` method to a
dedicated function.
This will allow to add more things to do in the `ready` with more focus.
For now, to avoid overloading dimail, we have defined a
time interval between each check request to dimail.
This interval should be configurable for testing and
different environments.
This provides a configurable OIDC introspection backend to be able to
call introspection endpoints which returns JSON data instead of an
encrypted JWT.
Two backends are currently defined:
- ResourceServerBackend` which expect a JSON response
- JWTResourceServerBackend which implements RFC 9701 and expects
JWE reponse.
There might be other cases (eg: ResourceServerBackend with JWT, JWS or
JWE, etc. but for now we don't use it, so we follow YAGNI).
This also allow to configure the claim to determine the "audience":
- client_id: for our Keycloak implementation
- aud: used by ProConnect
