On May 12, 2017 12:32 AM, "Melvyn Sopacua" <[email protected]> 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. Authentication backends aren’t required to check for the is_active flag but the default backend (ModelBackend <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend>) and the RemoteUserBackend <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend> do. You can use AllowAllUsersModelBackend <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.backends.AllowAllUsersModelBackend> or AllowAllUsersRemoteUserBackend <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.auth.backends.AllowAllUsersRemoteUserBackend> if you want to allow inactive users to login. " https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#django.contrib.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, or at least gather information as to why the account state changed. (second paragraph from docs) The term 'active' is ambiguous here, probably intentionally based on the wording in the Django docs. 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. For example, it does not make sense to display a user registration form to an authenticated user. A check for an anonymous user (either in the view or template) could allow them to see the form without running any 'has_perm' checks (which would fail in most cases), but would hide such functionality from authenticated users. Allowing them to do 'more' is inaccurate, rather you allow them to do something 'different' than an authenticated user. If someone is implementing multiple authentication/authorization back-ends, then they are probably aware of a potential issue with anonymous users and should handle those use cases appropriately. Please try to understand the whole thing and not just the bible quotes that fit you. I have no idea what this means, but it doesn't appear to add any value to the discussion. -James -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CA%2Be%2BciW6syWn1pK0_ZX2vYQe8dbb8X-CEH2%3DRcF0inmn9Z9QLQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
