Opened 7 years ago
Last modified 7 years ago
#29132 closed Bug
Incorrect update_last_login signal handler behavior when using custom User model with an arbitrary last_login attribute (not a Field instance) — at Version 1
Reported by: | Mikhail Porokhovnichenko | Owned by: | nobody |
---|---|---|---|
Component: | contrib.auth | Version: | 2.0 |
Severity: | Normal | Keywords: | last_login, update_last_login, signals, user_logged_in |
Cc: | 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 (last modified by )
Please note! It's not a #26823 duplicate, and it's just an issue related this one.
In the current implementation, a signal handler connects with a user model when this model has a last_login
field.
if hasattr(get_user_model(), 'last_login'): from .models import update_last_login user_logged_in.connect(update_last_login, dispatch_uid='update_last_login')
And it would work when there isn't a last_login
attribute in the custom user model. But what if I've inherited my custom model from AbstractUser
and dropped the last_login
by setting it to None
?
class User(AbstractBaseUser): last_login = None # Drop ``last_login`` field off
Technically, the model has a last_login
attribute, but it's not a field!
Suggesting change the check condition something like that:
last_login = getattr(get_user_model(), 'last_login', None) if last_login is not None: # ...
or even
if isisintance(last_login, models.Field): # ...