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 <https://docs.djangoproject.com/en/1.11/topics/auth/customizing/#authorization-for-inactive-users> 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 <https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#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. On Thu, May 11, 2017 at 12:24 AM, Melvyn Sopacua <[email protected]> wrote: > 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 > > -- > 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/5368536.rz2B7ec2LH%40devstation > <https://groups.google.com/d/msgid/django-users/5368536.rz2B7ec2LH%40devstation?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Sincerely yours, 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 [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/CAK52boVcM3c2q2Hi%2BQJjJ%3D2BQ7Rq65HXRXoO3Tcc-3bBse1z_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
