I haven't read the entire thread, did you account for custom user models that don't inherit from AbstractBaseUser? Do the system checks stil work? A Metaclass certainly would not, would it?
Cheers, /Markus On Thu, Apr 28, 2016 at 10:56:37AM -0700, Florian Apolloner wrote:
Are errors silence able via SILENCED_SYSTEM_CHECKS? If yes, I am against it -- this has to be an hard unrecoverable error for security reasons or fully backwards compatible (I am leaning towards the latter if possible in any way). On Thursday, April 28, 2016 at 5:01:04 PM UTC+2, Tim Graham wrote:Do you think my suggestion of a system check to flag this is unacceptable? diff --git a/django/contrib/auth/checks.py b/django/contrib/auth/checks.py index d1b0a44..347ad75 100644 --- a/django/contrib/auth/checks.py +++ b/django/contrib/auth/checks.py @@ -73,6 +73,14 @@ def check_user_model(app_configs=None, **kwargs): ) ) + if not isinstance(cls.is_anonymous, property): + errors.append( + checks.Error('%s.is_anonymous must be a property.' % cls) + ) + if not isinstance(cls.is_authenticated, property): + errors.append( + checks.Error('%s.is_authenticated must be a property.' % cls) + ) return errors On Thursday, April 28, 2016 at 10:25:01 AM UTC-4, Shai Berger wrote:On Monday 11 April 2016 20:13:02 Florian Apolloner wrote: > On Monday, April 11, 2016 at 6:57:46 PM UTC+2, Tim Graham wrote: > > I cannot think of much we could do besides monkey-patching the > > custom-user model. > > I would not call checking and rewriting the class in __new__ > monkey-patching, but… I think this is what we must do in order to keep backwards-compatibility while resolving the issue. If we don't resolve the issue, people will just keep using the method as if it were a property, opening themselves up in various ways; If we just make it a property in the builtin classes, custom user classes will re-introduce the issue. We can handle it in two ways, as far as I can see: A) What Florian alluded to above -- give AbstractBaseUser a metaclass which replaces the methods with Aymeric's "CallableBool"s B) Implement in AbstractBaseUser a __getattribute__ which, essentially, does the same thing when asked for the methods. When idea which I discarded was to "force" the attributes to be used as methods -- to use a callable which raises an exception when evaluated as boolean. But this replacement suffers exactly the same problems as the CallableBool replacement, unless also supported by "monkey patching" techniques, and a CallableBool is much more user-friendly. Have fun, Shai.-- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa589a27-cb1d-4233-b942-9f40d8416185%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20160428180722.GB20356%40inel.local. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
