#33561 closed New feature (fixed)
Allow syncing user attributes on every authentication with RemoteUserBackend.
Reported by: | Adrian Torres | Owned by: | Adrian Torres |
---|---|---|---|
Component: | contrib.auth | Version: | dev |
Severity: | Normal | Keywords: | RemoteUserBackend |
Cc: | Florian Apolloner | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If using a custom RemoteUserBackend, it is possible to want to synchronize any changes from the remote system back into the Django user records whenever authentication happens.
Currently, if any user attributes change in the remote system there is no easy way to reflect these changes back into the users in the Django system.
The goal of this feature is to introduce a new method in the django.contrib.auth.backends.RemoteUserBackend
class called synchronize_user
with a method signature equal to that of configure_user
(which it complements) that will be called in the authenticate
method of said class right after fetching the user from the database (if any), regardless of whether the user was unknown and created or otherwise.
Implementors can then override this method and implement data synchronization between the remote user and the Django user that will be applied on every user authentication attempt.
Change History (11)
comment:1 by , 3 years ago
Has patch: | set |
---|
comment:2 by , 3 years ago
Owner: | changed from | to
---|
comment:3 by , 3 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
comment:4 by , 3 years ago
Sure, but in my implementation the synchronization is done right before calling user_can_authenticate
whose output can change due to the synchronization.
Is it really necessary to start a new thread in the mailing list to have the patch be reconsidered?
Cheers,
Adrian
comment:5 by , 3 years ago
I think this would be a nice improvement. For one the suggested workaround does not work -- authentication checks could be done based on the assigned groups of the user which need to synchronized before authenticate
calls into user_can_authenticate
and not afterwards… This can be really useful with proxies like Authelia which sends along the following headers: Remote-User, Remote-Groups, Remote-Name, Remote-Email
Given that this is security related I rather see us providing a hook at the proper place than having users patch around this. I am not sure I agree with the patch though, we already do have configure_user
and it feels like we should just pass a boolean to that with the information if the user was just created or not (and move it around in code accordingly).
@Mariusz I was hesitant to reopen and accept the ticket after you have closed it, but I think it would be useful to support this (also I want to check if trc sends mail properly now :D)
comment:6 by , 3 years ago
Cc: | added |
---|
comment:7 by , 3 years ago
Has patch: | unset |
---|---|
Resolution: | wontfix |
Status: | closed → new |
Summary: | Synchronize user attributes on every authentication with RemoteUserBackend → Allow syncing user attributes on every authentication with RemoteUserBackend. |
Triage Stage: | Unreviewed → Accepted |
Agreed, it sounds reasonable to add created=False
to the configure_user()
signature and call configure_user(request, user, created=False)
when user already exists.
comment:9 by , 3 years ago
Status: | new → assigned |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Thanks for this ticket, however I don't see a strong reason for a new hook, you can achieve the same by overriding
authenticate()
, e.g.You can raise the idea on the DevelopersMailingList if you don't agree, to reach a wider audience and see what other think (see also triaging guidelines with regards to wontfix tickets).