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.
