Permissions for Anonymous Users in Django

[Uzair Tariq]

Does the Django have support for permission for the anonymous users? Reference Topic Link is making it ambiguous for me deciding between its support. Is it talking about a scenario where permission does support anonymous users and its possible consequences w.r.t inactive users? 

[Constantine Covtushenko]

Hi Uzair,

Can you please provide some use cases when there is needed such behavior?

Regards,

Constantine C.

On Tue, May 9, 2017 at 6:56 AM, Uzair Tariq <s.uzai...@gmail.com> wrote:

Does the Django have support for permission for the anonymous users? Reference Topic Link is making it ambiguous for me deciding between its support. Is it talking about a scenario where permission does support anonymous users and its possible consequences w.r.t inactive users? 

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@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/6bdc87ab-bc43-4a20-a988-1807f500c63b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sincerely yours,

Constantine C

[Uzair Tariq]

Consider a scenario in which an anonymous user search for the user profiles on the google. He gets public profile link to different social network which he can view as the anonymous user but if this user is registered and authenticated user on the social site but his profile is inactive at the moment he won't be able to view even the public profiles as his permission to the profile will be revoke thanks to the is_active authentication check. By default in this case Anonymous user will have greater surfing space compared with the inactive user.

My question was basically focused on permission support for the Anonymous users in Django and is confusing me with the topic Authorization for Anonymous and Authorization for inactive user's. In the former it's written clearly that there is no support for anonymous users but in later topic as referenced in my previous post it states The support for anonymous users in the permission system allows for a scenario where anonymous users have permissions to do something while inactive authenticated users do not .  This very line mentioned is making the whole state confusing about permission support in django.  

[Melvyn Sopacua]

On Wednesday 10 May 2017 09:49:48 Uzair Tariq wrote:

> Consider a scenario in which an anonymous user search for the user

> profiles on the google. He gets public profile link to different

> social network which he can view as the anonymous user but if this

> user is registered and authenticated user on the social site but his

> profile is inactive at the moment he won't be able to view even the

> public profiles as his permission to the profile will be revoke

> thanks to the is_active authentication check. By default in this case

> Anonymous user will have greater surfing space compared with the

> inactive user.

 

Negative.

 

An inactive user cannot log in, so for all intents and purposes she is an Anonymous user.

 

If you use a backend that allows logging in inactive users, then that's a bad choice to make. It's kind of the point of the is_active flag.

 

So either don't use the feature (use a custom user model that has no is_active flag) or use it and embrace it.

 

The reason for the is_active flag is that you can moderate bad conduct, lack of payments and so on. If you have no need for it, then that's a good case to implement a custom user model, but be aware, that you will have to delete staff accounts or unmark them as staff if they are no longer allowed to access to the admin.

--

Melvyn Sopacua

[Constantine Covtushenko]

Hi Uzair,

It seems like I see your point.

Let me head you on answer off your first question:

> Does the Django have support for permission for the anonymous users?

Open the link provided by you: Reference Topic Link and look paragraph above. There you can find following:

Django’s permission framework does not have a place to store permissions for anonymous users. However, the user object passed to an authentication backend may be an django.contrib.auth.models.AnonymousUser object, allowing the backend to specify custom authorization behavior for anonymous users.

As you can see permissions for Anonymous user should be defined inside some custom authentication backend logic.

I believe that you should write your own Authentication Backend to allow what you need for Anonymous user cases.

Hope that helps.

Regards,

Constantine C.

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@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/5368536.rz2B7ec2LH%40devstation.

For more options, visit https://groups.google.com/d/optout.

[Uzair Tariq]

A Bundle of thank Constantine Covtushenko now the working to Authentication Backend for anonymous and inactive users is clear. Just one last question does the scenario that i defined in my example when you asked for the use case fit this line from the same topic.

 The support for anonymous users in the permission system allows for a scenario where anonymous users have permissions to do something while inactive authenticated users do not.

Can you explain your deduction( The semantics of the line ) from this line of the topic with an example?

On Tuesday, May 9, 2017 at 8:56:47 AM UTC+5, Uzair Tariq wrote:

[Constantine Covtushenko]

Hi Uzair,

Please find my answer in blue:

On Thu, May 11, 2017 at 9:10 PM, Uzair Tariq <s.uzai...@gmail.com> wrote:

A Bundle of thank Constantine Covtushenko now the working to Authentication Backend for anonymous and inactive users is clear. Just one last question does the scenario that i defined in my example when you asked for the use case fit this line from the same topic.

 The support for anonymous users in the permission system allows for a scenario where anonymous users have permissions to do something while inactive authenticated users do not.

Can you explain your deduction( The semantics of the line ) from this line of the topic with an example?

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.

That is why we can distinguish between them - 'not logged in' VS 'logged in'.

That is why it is said 'inactive authenticated users'.

Examples:

1. Someone just opens any page with public access - Anonymous User case

2. A Person which is logged in but did not confirmed their email or something to activate their account and then opens page with public access  - Authenticated But Is Not Active User.

Hope that helps,

Regards,

Constantine C.

On Tuesday, May 9, 2017 at 8:56:47 AM UTC+5, Uzair Tariq wrote:

Does the Django have support for permission for the anonymous users? Reference Topic Link is making it Uzair, for me deciding between its support. Is it talking about a scenario where permission does support anonymous users and its possible consequences w.r.t inactive users? 

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@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/4d116642-d2ed-4512-a2e8-dd44b715a76a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Uzair Tariq]

Thanks man! So basically my example and deduction of the sentence was right about the anonymous and inactive authenticated users where i stated that the anonymous may be able to view the public profile but if it's an inactive authenticated user because of some reason he may be directed to some other error page because of is_active() permission check and he wont be able to view even public profile because the whole system will logically be promoting about account activation or any sort of equivalent reason/error.

On Tuesday, May 9, 2017 at 8:56:47 AM UTC+5, Uzair Tariq wrote:

[Constantine Covtushenko]

You are welcome :)

Have a fun with you project and Django.

Django is very great!

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to django...@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/8a4851aa-77a5-4c9e-b0d6-dc31a85b3262%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Melvyn Sopacua]

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.

 

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.

 

Please try to understand the whole thing and not just the bible quotes that fit you.

 

To prevent the anonymous user from doing things, you shall use LoginRequiredMixin or the corresponding decorator.

--

Melvyn Sopacua

[James Schneider]

On May 12, 2017 12:32 AM, "Melvyn Sopacua" <m.r.s...@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. Authentication backends aren’t required to check for the is_active flag but the default backend (ModelBackend) and the RemoteUserBackend do. You can use AllowAllUsersModelBackend or 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

[James Schneider]

On May 11, 2017 12:44 PM, "Uzair Tariq" <s.uzai...@gmail.com> wrote:

Thanks man! So basically my example and deduction of the sentence was right about the anonymous and inactive authenticated users where i stated that the anonymous may be able to view the public profile but if it's an inactive authenticated user because of some reason he may be directed to some other error page because of is_active() permission check and he wont be able to view even public profile because the whole system will logically be promoting about account activation or any sort of equivalent reason/error.

While your assertion is correct, if you do not allow inactive users to authenticate, then part of your work flow for setting them as inactive should include clearing any existing sessions for that user when the flag is flipped. 

This way, your inactive users should become anonymous users automatically when they next visit your site (you may need other logic for redirects back to the original page, since the browser may still think it is logged in). No need to worry about authorization for inactive authenticated users in that case, since you won't have any.

-James

[Melvyn Sopacua]

On Friday 12 May 2017 02:38:23 James Schneider wrote:

> On May 12, 2017 12:32 AM, "Melvyn Sopacua" <m.r.s...@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

[Uzair Tariq]

Thanks James for the Tip about clearing session data.