On Mon, Oct 21, 2013 at 7:17 AM, Tino de Bruijn <[email protected]> wrote:
> > On Mon, Oct 21, 2013 at 12:25 AM, Harry Percival <[email protected] > > wrote: > >> I don't care about last_login! Can this be circumvented? Should that >> signal be optional, or gracefully handle the case where the user model has >> no last_login field? Should I log this as a bug? > > > No, this is not a bug, it is by design. Django needs the last_login field > for generating password reset tokens [0], and I guess you do want to leave > that functionality in there. It is also not going to change anytime soon. > Please look at another recent thread on this list about this same subject, > and some reasoning from the core devs behind it. > > If you really want a 'bare' User model, you can, you just can't use other > contrib.auth stuff and contrib.admin stuff, as they expect more than just > and identifier (like password reset, permissions and groups). > Actually, until the introduction of the login signal, this was untrue. I looked into this at DjangoCon US specifically because of a request from Harry, and I got a passwordless login to admin working fine. Groups and permissions are also unnecessary -- you just need to implement the has_permission() family of APIs, and they can be implemented with a simple "return True" result, or by calls on external authentication APIs if they're available. Harry's use case is an interesting one -- his authentication is being done entirely by an external process, so there's no need for a password field. Yes, he could just have the password and last_login fields and not use it, but why should he need to carry around he extra weight when Django doesn't need it. Harry - to address your original question: the immediate workaround is to make sure your user model can handle receiving a save request with an update_fields argument that contains last_login: class MyUser(Model): … def save(self, *args, **kwargs): fields = kwargs.pop('update_fields', []) if fields != ['last_login']: return super(MyUser, self).save(*args, **kwargs) You could also handle this by disconnecting the 'user_logged_in' signal: user_logged_in.disconnect(update_last_login) The catch here will be getting this called in the right place; as is usually the case with Django signals, guaranteeing order of execution is the problem. The "right" place will depend on the exact properties of your project. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_8CBWoPqyDGVr6C42znt9QFimXfK9ErXYAvU62rAigzg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
