On Friday 12 May 2017 02:38:23 James Schneider wrote: > On May 12, 2017 12:32 AM, "Melvyn Sopacua" <m.r.sopa...@gmail.com> > wrote: > On Thursday 11 May 2017 21:59:48 Constantine Covtushenko wrote: > > Let us check terms: > > > > Anonymous User - is one that is not authenticated. It refers to > > > > scenarios when someone opens site pages. Even robots can be such > > > > users. > > > > > > > > Inactive Authenticated User - is one that successfully logged in. > > *sigh*. > > Why would you allow that? > > Explain the upside. > > > > In a good system there are no inactive **authenticated** users. > > > Not necessarily. It depends on how narrowly you define 'is_active'. > Even the user model in the recent Django releases note ambiguity: > > "is_active: Boolean. Designates whether this user account should be > considered active. We recommend that you set this flag to False > instead of deleting accounts; that way, if your applications have any > foreign keys to users, the foreign keys won’t break. > > This doesn’t necessarily control whether or not the user can log in.
I don't see the ambiguity here. In fact it enforces the notion that inactive users should not be able to log in, because it makes them analog to deleted users. > You can use AllowAllUsersModelBackend > <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contr > ib.auth.backends.AllowAllUsersModelBackend> or > AllowAllUsersRemoteUserBackend > <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contr > ib.auth.backends.AllowAllUsersRemoteUserBackend> if > you want to allow inactive users to login. " Only use case for this I can see is some form of resubscribe tease (downgraded but slightly better access) that is better handled with proper subscription levels. I don't even get why it's in the core, as it is trivial to write and forces one to evaluate the consequences. > https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contri > b.auth.models.User.is_active > > It depends on how the user work flow is built. In some cases, the flag > will disallow the user to log in at all, as you've stated. It renders > the account unusable, but keeps it in the system for reference. This > is the intention of the first paragraph from the docs. > > In other cases, this flag may represent a user that has changed state > for some reason (password expired, content subscription ended, length > of time since last login, etc.). These accounts should be able to at > least log in to the system with a minimal set of privileges necessary > to restore the account to it's normal state, No they don't need to. What you need is to know why authentication failed. You have all the information to present a form that reinstates the account. And instead of guarding inactive user permissions in numerous places, you only have to do one perhaps two queries to fetch any additional information you'd need in one place. Again - I don't see the upside. > Also good luck restricting permissions for Anonymous users. The > functionality exists for allowing anonymous users to do *more*. I'm > not saying you can't do it. But if another authentication backend > *grants* the permission, there really isn't anything you can do about > it. > > > If that's the case, the permission system may be implemented by the > programmer incorrectly. Anonymous users with the standard > authorization back-end cannot have privileges. You end up authorizing > based on the type of user, not a permission associated with a user. You missed some context. The intention of OP is to write a custom backend that stores privileges for Anonymous users. So far so good, but, the expectation is to further restrict them. Since permissions are implemented as "the first backend that says "yes", we grant it", restriction becomes troublesome. In any decent size project there's more then one authentication backend involved and keeping track of who allows what becomes ugly real quick. -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1578746.FViHn1q6LJ%40devstation. For more options, visit https://groups.google.com/d/optout.
