Re: Signal limitations with custom models!

[Uzair Tariq]

Thanks man! Actually i was thinking the same thing as mentioned in the 
question because that's the only valid logical reason i can come up with 
after viewing the ticket. Anyways *Thanks again*

On Thursday, May 18, 2017 at 2:53:57 AM UTC+5, James Schneider wrote:
>
>
>
> On May 17, 2017 7:59 AM, "Uzair Tariq" <s.uzai...@gmail.com > 
> wrote:
>
> So i read about *Signal Limitations *in Django that comes up with user 
> custom models and you can't use *get_user_model()* as according to this link 
> <https://code.djangoproject.com/ticket/19218>it's clearly stated that the 
> reason for it is because the module is not completely loaded at this point 
> and the solution is to defer the function call until the whole module is 
> loaded. So why not this case does not apply to Default user model i.e. 
> *AbstractUser* in django? Is it because of execution order or is it some 
> back end One Time execution logic that loads the default models only once 
> in a cache and retrieves it every time but not in custom user model case?
>
>
> From my brief reading of the ticket, it looks like the signal call for the 
> built-in User (not AbstractUser, which is never directly used) only works 
> because that model is already loaded by the time the custom models are 
> inspected. 
>
> My guess is that the internal Django models are loaded first, and then app 
> models are loaded. Since you're defining the signal handler in your app, 
> you would be able to reference the built-in models but not any models that 
> haven't already been inspected. 
>
> I doubt there is any magic involved, it's technically a race condition.
>
> Admittedly, I'm not deeply familiar with the mechanics in this scenario, 
> but it's my best educated guess.
>
> -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 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/30421fe9-a1e5-47b2-8f72-d348639a255e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Signal limitations with custom models!

[Uzair Tariq]

So i read about *Signal Limitations *in Django that comes up with user 
custom models and you can't use *get_user_model()* as according to this link 
it's clearly stated that the 
reason for it is because the module is not completely loaded at this point 
and the solution is to defer the function call until the whole module is 
loaded. So why not this case does not apply to Default user model i.e. 
*AbstractUser* in django? Is it because of execution order or is it some 
back end One Time execution logic that loads the default models only once 
in a cache and retrieves it every time but not in custom user model case?

-- 
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/68a0e076-a288-4be8-a1da-6941d0713ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Permissions for Anonymous Users in Django

[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:
>
> Does the Django have support for permission for the anonymous users? 
> Reference 
> Topic Link 
> <https://docs.djangoproject.com/en/1.11/topics/auth/customizing/#authorization-for-inactive-users>
>  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+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/8a4851aa-77a5-4c9e-b0d6-dc31a85b3262%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Permissions for Anonymous Users in Django

[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:
>
> Does the Django have support for permission for the anonymous users? 
> Reference 
> Topic Link 
> <https://docs.djangoproject.com/en/1.11/topics/auth/customizing/#authorization-for-inactive-users>
>  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+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/4d116642-d2ed-4512-a2e8-dd44b715a76a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Permissions for Anonymous Users in Django

[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.  

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 
> <https://docs.djangoproject.com/en/1.11/topics/auth/customizing/#authorization-for-inactive-users>
>  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+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/762eb92c-42ac-45b3-aa2b-4421795a98c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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? 

-- 
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/6bdc87ab-bc43-4a20-a988-1807f500c63b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django authentication security check against LDAP

[Uzair Tariq]

While studying the Authentication Views in Django I came across some of the 
build in views including password reset view. I got hang of its basic 
working mechanism while reading the documentation I encountered the line 
promoting the use of *set_unusable_password()* in Djagno authentication 
against *LDAP networks*. I googled and found some of the useful links 
defining LDAP networks e.g. 
 but 
I was not able to understand the possible vulnerabilities to the LDAP 
authentication system that may arise when the set_unusable_password flag is 
not set and the system is requested a password change request. Basically 
what I am trying to ask is what kind of misuse can occur in case of LDAP 
authentication and set_unusable_function not being used as said in the 
following context of the password reset view in Django. Can anyone please 
kindly highlight some of the misuses I will be really grateful. The Link 

 to 
the topic is here and *Method Link 
*.
 
Thanks in *Advance*.

-- 
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/04815d24-898b-4e03-b50d-24cac2094942%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.