Re: Overriding Class-based View Form Validation

[Curtis Maloney]

Firstly, I think this query really belongs in django-users  ... this list
is about development _of_ django, not _with_ django.

Secondly, why not override get_form_kwargs [1] to add the user into
creating the form class?

But yes, validation all belongs inside the form class, ideally.

[1]
https://docs.djangoproject.com/en/1.7/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.get_form_kwargs

On 11 December 2014 at 09:26, Greg Back  wrote:
>
> Sorry, I accidentally sent this before finishing the background. What I
> meant to say:
>
> I am writing an application where a model (I'll call it `Thing`) has a
> ForeignKey to User and a CharField ("name"), among some other fields. I
> would like "name" to be unique for any given user; I'm using
> `unique_together` in `class Meta:` to accomplish this. I have a CreateView
> subclass which allows users to create new Things; the `user` field is
> excluded from the form, and automatically set in the View (extracting from
> `self.request`). I was previously doing this in the `form_valid` function,
> but realized that this is being called after the form is already validated
> (without a User). By the time the object is saved to the database, the
> `user` field is set, so the database raises an IntegrityError.
>
> I hacked around this by overriding `get_form` to call the parent class,
> then adding the request.user to the form.instance. This works, but has the
> side effect of also being called during GET requests, which doesn't break
> anything but is suboptimal.
>
> Does that all make sense? Am I missing a more obvious way of doing this?
>
> Thanks,
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3353afdb-7070-49bb-9d45-ea072ac9bbb5%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSARu6yQDKtP9hJ6CQuLRPuYEYgOXjDMyB-%3D%3DVy%2BNXv8LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Error accessing the table from an app with label changed

[Tim Graham]

I guess this is your ticket here: 
https://code.djangoproject.com/ticket/23981

I couldn't reproduce the issue so please provide more details.

On Wednesday, December 10, 2014 2:19:41 PM UTC-5, Paulo Maciel wrote:
>
> I put in *db_table* the table name with the new label prefix and it 
> works, it would be better to automatically identify the new name label 
> created by AppConfig. This seems to be a bug
>
> Em quarta-feira, 10 de dezembro de 2014 17h07min15s UTC-2, Paulo Maciel 
> escreveu:
>>
>> I created an app and using AppConfig I changed the label to another name 
>> (abc to my_abc). The migration was successful and the table was created 
>> with the label prefix. But when I access the page, Django emits an error 
>> that is trying to access the table without taking into account that has 
>> changed the name of the label, it is trying to access the table "abc", but 
>> should access "my_abc".
>>
>> ProgrammingError
>> relation "abc" does not exist
>>
>> Is it a bug or am I doing something wrong?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/907a6c92-a32d-40cd-b916-12317b3f6e3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Roman Akopov]

I've researched a little more, and looks like there is BACKEND_SESSION_KEY 
so it is possible to annotate user with backend on subsequent requests.
https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L169
Look like it should be a one line fix for this like
user.backend = backend
I think this will not break any existing code.

At non-request situations for non-authenticated User model, i.e. 
instantiated from database, or just created and saved, we can simply 
fallback to old behavior. Actually, I think this is correct, because a user 
can have valid credentials in various backends simultaneously. Imagine we 
have three backends: Model, LDAP, SMTP. So if you authenticate with 
credentials valid for SMTP backend, you can't change password because SMTP 
does not support this at all. It should be something like methods throwing 
NotImplementedError. If you authenticate with credentials valid for LDAP 
backend you can change password and that change will be performed against 
LDAP. If you authenticate with credentials valid for Model backend you can 
change password in model database. This looks like consistent behavior, 
since you change password you just used to authenticate, not some other 
password you probably even do not know about. And if no custom backend is 
registered or no backend information is available, we fallback to default 
one. Of course there is a question, how to reset LDAP password from admin 
interface. The answer will be "you cannot". This looks sane for me, because 
end-users are happy using just one software for all their tasks and LDAP 
administrator should use LDAP tools for administrative tasks anyway, and 
password reset is just a small one, there will be permission management, 
group membership and all of these tools should not be doubled in Django 
admin.

On Thursday, December 11, 2014 7:49:05 PM UTC+4, Tim Graham wrote:
>
> User is only annotated with backend when calling authenticate(). On 
> subsequent requests, or in non-request situations like the Python shell, 
> how will you know which backend to delegate to?
>
> How do existing LDAP backends deal with this problem? (or do they just 
> ignore it?)
>
> On Thursday, December 11, 2014 4:40:09 AM UTC-5, Roman Akopov wrote:
>>
>> Hello,
>>
>> This is my fist post, so I'm not fully aware of any posting policies you 
>> have, but at least I'll try to present my ideas in clear way.
>>
>> *Very brief description of what I suggest:*
>>
>> Optionally delegate password change and password reset to authentication 
>> backend.
>>
>> *Motivation:*
>>
>> Django framework is very popular and widely used not only for public, but 
>> for private projects too. To make it clear, by private I mean not only 
>> personal, but mostly corporate intranet projects.
>>
>> One of the important part of any corporate project is some kind of single 
>> sing on (SSO) or, at least, integration with external authentication 
>> backend. From my experience it may be any service able to validate 
>> credentials. LDAP is most often used for authentication purposes, however, 
>> it is not the only available choice. I had projects with authentication 
>> delegated to custom HTTP web-services, SMTP, POP3 and IMAP servers, and so 
>> on. Corporate intranet you have to deal with may be a zoo of unbelievably 
>> non-standard software. Also, even if we’ll talk about LDAP, it may be a 
>> few, more than one, LDAP servers you have to try authentication against, 
>> like Active Directory and OpenLDAP.
>>
>> Current implementation of User model as well as standard forms, delegates 
>> to backend authentication only, but not password reset or change. This 
>> forces to reimplementation of user model and/or reimplementation of 
>> standard forms for very common tasks, high coupling and bad architecture. 
>> Also, if left as is, behavior is very inconsistent, since user is 
>> authenticated against one password database (LDAP), but changes or resets 
>> password in another (relational model database). And while LDAP may be 
>> administered externally by standard web tools, this is not a good option 
>> too, since means inconsistent user experience. And custom HTTP services 
>> cannot be administered by standard tools at all.
>>
>> *Implementation:*
>>
>> As far as I can see User model is already annotated with backend field
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L75
>>  
>> so it is possible, and looks simple, to delegate password change and 
>> reset to backend, if backend support these operations, which means 
>> AbstractBaseUser.set_password method
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>>  
>>
>> should be refactored to two methods: reset_password and change_password 
>> instead of one set_password, and these two method should delegate operation 
>> to backend if supported. (set_password may be left as alias of 
>> reset_password). Signatures will be
>>
>> 

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Roman Akopov]

All right, that's what I've missed. Thank you, for this point.

Existing LDAP backends I've reviewed do not support password change/reset 
at all.


On Thursday, December 11, 2014 7:49:05 PM UTC+4, Tim Graham wrote:
>
> User is only annotated with backend when calling authenticate(). On 
> subsequent requests, or in non-request situations like the Python shell, 
> how will you know which backend to delegate to?
>
> How do existing LDAP backends deal with this problem? (or do they just 
> ignore it?)
>
> On Thursday, December 11, 2014 4:40:09 AM UTC-5, Roman Akopov wrote:
>>
>> Hello,
>>
>> This is my fist post, so I'm not fully aware of any posting policies you 
>> have, but at least I'll try to present my ideas in clear way.
>>
>> *Very brief description of what I suggest:*
>>
>> Optionally delegate password change and password reset to authentication 
>> backend.
>>
>> *Motivation:*
>>
>> Django framework is very popular and widely used not only for public, but 
>> for private projects too. To make it clear, by private I mean not only 
>> personal, but mostly corporate intranet projects.
>>
>> One of the important part of any corporate project is some kind of single 
>> sing on (SSO) or, at least, integration with external authentication 
>> backend. From my experience it may be any service able to validate 
>> credentials. LDAP is most often used for authentication purposes, however, 
>> it is not the only available choice. I had projects with authentication 
>> delegated to custom HTTP web-services, SMTP, POP3 and IMAP servers, and so 
>> on. Corporate intranet you have to deal with may be a zoo of unbelievably 
>> non-standard software. Also, even if we’ll talk about LDAP, it may be a 
>> few, more than one, LDAP servers you have to try authentication against, 
>> like Active Directory and OpenLDAP.
>>
>> Current implementation of User model as well as standard forms, delegates 
>> to backend authentication only, but not password reset or change. This 
>> forces to reimplementation of user model and/or reimplementation of 
>> standard forms for very common tasks, high coupling and bad architecture. 
>> Also, if left as is, behavior is very inconsistent, since user is 
>> authenticated against one password database (LDAP), but changes or resets 
>> password in another (relational model database). And while LDAP may be 
>> administered externally by standard web tools, this is not a good option 
>> too, since means inconsistent user experience. And custom HTTP services 
>> cannot be administered by standard tools at all.
>>
>> *Implementation:*
>>
>> As far as I can see User model is already annotated with backend field
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L75
>>  
>> so it is possible, and looks simple, to delegate password change and 
>> reset to backend, if backend support these operations, which means 
>> AbstractBaseUser.set_password method
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>>  
>>
>> should be refactored to two methods: reset_password and change_password 
>> instead of one set_password, and these two method should delegate operation 
>> to backend if supported. (set_password may be left as alias of 
>> reset_password). Signatures will be
>>
>> def reset_password(self, new_password)
>> def change_password(self, old_password, new_password)
>>
>> Also authentication forms
>>
>> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>>  
>>
>> should be refactored to use these new reset_password and change_password 
>> methods. There must be two methods, as change_password and reset_password 
>> may not be both available, also change_password requires old password as 
>> backend may require it. Returning to LDAP, there may be various policies 
>> which should be respected, like not to change password too often, but reset 
>> whenever you want, so we need two separate methods.
>>
>> *Backward compatibility:*
>>
>> As far as I can see change is backwards compatible. Authentication 
>> backends not providing extra operations will behave old way without any 
>> change.
>>
>> *Patch:*
>>
>> I wanted my design to be reviewed before I’ll try to provide any patch. 
>> I'mm pretty sure I've missed something, so discussion is welcome. Also, 
>> this will be my first code for Django project, so I'll probably break some 
>> rules and will need some help.
>> With best regards,
>> Roman 
>> ...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Tim Graham]

User is only annotated with backend when calling authenticate(). On 
subsequent requests, or in non-request situations like the Python shell, 
how will you know which backend to delegate to?

How do existing LDAP backends deal with this problem? (or do they just 
ignore it?)

On Thursday, December 11, 2014 4:40:09 AM UTC-5, Roman Akopov wrote:
>
> Hello,
>
> This is my fist post, so I'm not fully aware of any posting policies you 
> have, but at least I'll try to present my ideas in clear way.
>
> *Very brief description of what I suggest:*
>
> Optionally delegate password change and password reset to authentication 
> backend.
>
> *Motivation:*
>
> Django framework is very popular and widely used not only for public, but 
> for private projects too. To make it clear, by private I mean not only 
> personal, but mostly corporate intranet projects.
>
> One of the important part of any corporate project is some kind of single 
> sing on (SSO) or, at least, integration with external authentication 
> backend. From my experience it may be any service able to validate 
> credentials. LDAP is most often used for authentication purposes, however, 
> it is not the only available choice. I had projects with authentication 
> delegated to custom HTTP web-services, SMTP, POP3 and IMAP servers, and so 
> on. Corporate intranet you have to deal with may be a zoo of unbelievably 
> non-standard software. Also, even if we’ll talk about LDAP, it may be a 
> few, more than one, LDAP servers you have to try authentication against, 
> like Active Directory and OpenLDAP.
>
> Current implementation of User model as well as standard forms, delegates 
> to backend authentication only, but not password reset or change. This 
> forces to reimplementation of user model and/or reimplementation of 
> standard forms for very common tasks, high coupling and bad architecture. 
> Also, if left as is, behavior is very inconsistent, since user is 
> authenticated against one password database (LDAP), but changes or resets 
> password in another (relational model database). And while LDAP may be 
> administered externally by standard web tools, this is not a good option 
> too, since means inconsistent user experience. And custom HTTP services 
> cannot be administered by standard tools at all.
>
> *Implementation:*
>
> As far as I can see User model is already annotated with backend field
>
> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L75
>  
> so it is possible, and looks simple, to delegate password change and reset 
> to backend, if backend support these operations, which means 
> AbstractBaseUser.set_password method
>
> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>  
>
> should be refactored to two methods: reset_password and change_password 
> instead of one set_password, and these two method should delegate operation 
> to backend if supported. (set_password may be left as alias of 
> reset_password). Signatures will be
>
> def reset_password(self, new_password)
> def change_password(self, old_password, new_password)
>
> Also authentication forms
>
> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>  
>
> should be refactored to use these new reset_password and change_password 
> methods. There must be two methods, as change_password and reset_password 
> may not be both available, also change_password requires old password as 
> backend may require it. Returning to LDAP, there may be various policies 
> which should be respected, like not to change password too often, but reset 
> whenever you want, so we need two separate methods.
>
> *Backward compatibility:*
>
> As far as I can see change is backwards compatible. Authentication 
> backends not providing extra operations will behave old way without any 
> change.
>
> *Patch:*
>
> I wanted my design to be reviewed before I’ll try to provide any patch. 
> I'mm pretty sure I've missed something, so discussion is welcome. Also, 
> this will be my first code for Django project, so I'll probably break some 
> rules and will need some help.
> With best regards,
> Roman 
> ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba661064-25dc-48ce-9b88-e5b1df1709e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Feature request: delegate more password related operations to auth backends (#23896)

[Roman Akopov]

 

Hello,

This is my fist post, so I'm not fully aware of any posting policies you 
have, but at least I'll try to present my ideas in clear way.

*Very brief description of what I suggest:*

Optionally delegate password change and password reset to authentication 
backend.

*Motivation:*

Django framework is very popular and widely used not only for public, but 
for private projects too. To make it clear, by private I mean not only 
personal, but mostly corporate intranet projects.

One of the important part of any corporate project is some kind of single 
sing on (SSO) or, at least, integration with external authentication 
backend. From my experience it may be any service able to validate 
credentials. LDAP is most often used for authentication purposes, however, 
it is not the only available choice. I had projects with authentication 
delegated to custom HTTP web-services, SMTP, POP3 and IMAP servers, and so 
on. Corporate intranet you have to deal with may be a zoo of unbelievably 
non-standard software. Also, even if we’ll talk about LDAP, it may be a 
few, more than one, LDAP servers you have to try authentication against, 
like Active Directory and OpenLDAP.

Current implementation of User model as well as standard forms, delegates 
to backend authentication only, but not password reset or change. This 
forces to reimplementation of user model and/or reimplementation of 
standard forms for very common tasks, high coupling and bad architecture. 
Also, if left as is, behavior is very inconsistent, since user is 
authenticated against one password database (LDAP), but changes or resets 
password in another (relational model database). And while LDAP may be 
administered externally by standard web tools, this is not a good option 
too, since means inconsistent user experience. And custom HTTP services 
cannot be administered by standard tools at all.

*Implementation:*

As far as I can see User model is already annotated with backend field
https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L75
 
so it is possible, and looks simple, to delegate password change and reset 
to backend, if backend support these operations, which means 
AbstractBaseUser.set_password method
https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226 

should be refactored to two methods: reset_password and change_password 
instead of one set_password, and these two method should delegate operation 
to backend if supported. (set_password may be left as alias of 
reset_password). Signatures will be

def reset_password(self, new_password)
def change_password(self, old_password, new_password)

Also authentication forms
https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226 

should be refactored to use these new reset_password and change_password 
methods. There must be two methods, as change_password and reset_password 
may not be both available, also change_password requires old password as 
backend may require it. Returning to LDAP, there may be various policies 
which should be respected, like not to change password too often, but reset 
whenever you want, so we need two separate methods.

*Backward compatibility:*

As far as I can see change is backwards compatible. Authentication backends 
not providing extra operations will behave old way without any change.

*Patch:*

I wanted my design to be reviewed before I’ll try to provide any patch. 
I'mm pretty sure I've missed something, so discussion is welcome. Also, 
this will be my first code for Django project, so I'll probably break some 
rules and will need some help.
With best regards,
Roman

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/280b8270-19b7-4ad4-840c-7f716564102d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.