Re: is_authenticated as property

Well, actually, there is a problem with the check approach: People use proxy models with user models, to account for different types of users; and it could be that the actual class is decided before the user is authenticated (because of different entry URLs, different authentication backends,

Re: is_authenticated as property

On Thursday, April 28, 2016 at 10:48:02 PM UTC+2, Shai Berger wrote: > > The problem with these suggestions is that they create a user object > during > checks, and that might be an obstacle for some users (side effects and > required > initializer parameters are the two most obvious

Re: is_authenticated as property

On Thursday, April 28, 2016 at 8:07:36 PM UTC+2, Markus Holtermann wrote: > > 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? Yeah, we probably

Re: is_authenticated as property

Right, right and right. Tim, I somehow missed that suggestion. It is certainly workable. Markus, Custom user classes which do not inherit AbstractBaseUser are a point I hadn't considered, and in fact they make my suggestions problematic, leaving _only_ the checks approach. However,

Re: is_authenticated as property

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

Re: is_authenticated as property

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

Re: is_authenticated as property

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

Re: is_authenticated as property

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__ >

Re: is_authenticated as property

On Thursday, April 28, 2016 at 8:37:09 AM UTC+2, Sven R. Kunze wrote: > > Am Montag, 25. April 2016 10:38:23 UTC+2 schrieb Florian Apolloner: >> >> Absolutely not, what are you basing your justification on? >> > > The fact that I know real cases where this was a security issue. I'd > rather have

Re: is_authenticated as property

Am Montag, 25. April 2016 10:38:23 UTC+2 schrieb Florian Apolloner: > > Absolutely not, what are you basing your justification on? > The fact that I know real cases where this was a security issue. I'd rather have a backwards incompatibility than a security hole. But that may just be me. One

Re: is_authenticated as property

On Saturday, April 23, 2016 at 11:02:07 PM UTC+2, Sven R. Kunze wrote: > > Am Montag, 11. April 2016 18:57:46 UTC+2 schrieb Tim Graham: >> >> Do you think the backwards incompatibility is justified here or do you >> prefer some other solution? >> > > I for one think it is justified here. >

Re: is_authenticated as property

Am Montag, 11. April 2016 18:57:46 UTC+2 schrieb Tim Graham: > > Do you think the backwards incompatibility is justified here or do you > prefer some other solution? > I for one think it is justified here. -- You received this message because you are subscribed to the Google Groups "Django

Re: is_authenticated as property

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… -- You received this message because you are

Re: is_authenticated as property

Florian has raised the issue of custom user models which define these methods, "Allowing custom user models to have a method is a security risk since all checks will now return true." I proposed a compatibility system check error to detect that situation to alert the user. Do you think the

Re: is_authenticated as property

2015-12-03 7:02 GMT+01:00 Josh Smeaton : > I think we should be asking.. why not? If there's not a good reason not > to, let's make it a callable and a property. > The original discussion dates back to 2008; back then I believe we were slightly more resistant to change,

Re: is_authenticated as property

I agree with the ticket. The imbalance between is_superuser and is_authenticated() should be enough to consider updating the API. The security concerns and, in particular, Aymeric's Jinja example, make this ticket more compelling. I think we should be asking.. why not? If there's not a good

Re: is_authenticated as property

On Wednesday 02 December 2015 18:51:03 Aymeric Augustin wrote: > > We could implement a property that returns an object: > > - that is still callable, for backwards compatibility > - that evaluates correctly in a boolean context > > Then we can consider deprecating the ability to call it. > >

Re: is_authenticated as property

>> > is_staff, is_active, is_superuser are attributes. >>> > >>> > is_anonymous, is_authenticated are methods. >>> > >>> > This is insecure if you are not careful while programming: >>> > >>> > if user.is_authenticated

Re: is_authenticated as property

is_anonymous, is_authenticated are methods. >> > >> > This is insecure if you are not careful while programming: >> > >> > if user.is_authenticated: >> > # Always true, since it is a method! >> > >> > It would be nice to find a solution. Here

Re: is_authenticated as property

> My own opinion is that if you don't have tests to catch the mistake in the first place, you're doing it wrong. Not sure I'd necessarily agree there - easy to miss the anonymous case. No obvious best thing to do tho'. On the one hand it's too easy to get wrong, on the other the current visual

Re: is_authenticated as property

; # Always true, since it is a method! > > > > It would be nice to find a solution. Here is what I thought: > > > > Make is_authenticated a property which returns a object > > which evaluates to the proper boolean value. This object &g

is_authenticated as property

: Make is_authenticated a property which returns a object which evaluates to the proper boolean value. This object has a method __call__ which returns the same value. This is backwards compatible. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de