Re: NIST password guidelines [was: vulnerability in password reset]

[Erik Romijn]

Hello,

Django has had password validation built in as of 1.9. As far as I can see, all 
guidelines you refer to are already implemented there, and enabled by default 
in new projects. Could you elaborate on what changes you think we need to make?

Erik

> On 23 Nov 2016, at 16:21, William Hakizimana  wrote:
> 
> While we are at it, could we implement these NIST new password guidelines 
> 
>  into django? Just
> 
> On Monday, November 21, 2016 at 3:13:21 PM UTC-6, Tim Graham wrote:
> We don't normally give security advisories for issues that affect only
> the master branch, but in this case we've made an exception as the issue
> could be high impact.
> 
> Please see the blog post for details:
> https://www.djangoproject.com/weblog/2016/nov/21/passwordresetconfirmview-security-advisory/
>  
> 
> 
> -- 
> 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/71b646e9-9a39-4e47-9aa9-c6cfacd82b6e%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0D5D730A-3C3E-4886-8C9C-3FEC814F5B1B%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

[Erik Romijn]

Hello,

Thank you for raising this, Markus.

I am +1 to everything Baptiste said.

In particular, if our conclusion of this bug would be that CBV are entirely 
unsuitable for security sensitive features, I don’t think removing CBV for auth 
is enough. Because by that logic, our users will be making the same mistakes, 
and the logical step would be to remove CBV from Django entirely. Which is not 
something I would advocate.

If we are concerned about it being easier to cause vulnerabilities in CBV, I 
think updates to the documentation might be the best place to address this.

Erik

> On 22 Nov 2016, at 09:02, Baptiste Mispelon  wrote:
> 
> Hi Markus,
> 
> Thanks for your clear description and for bringing this up for discussion.
> 
> I don't agree with your conclusions though.
> 
> 
> 1) Keeping around two implementations of auth views seems counter-productive 
> to me in terms of security because it effectively doubles the potential for 
> bugs or security issues (not   to mention the added maintenance work). We 
> should have only one set of auth views.
> 
> 2) Our users want more extension hooks for auth views. If we don't provide 
> them, some users will end up copy/pasting Django's views and tweak what they 
> need (I have done that myself more than once). This copy/pasted code then 
> won't receive updates (potentially security-related) when Django changes, 
> which also presents a danger to our users (unless they track changes in the 
> code, which is unlikely).
> 
> 3) Your description of the security issues seems quite alarming but how does 
> it compare with others in the past? To me, a 4-month window actually seems 
> quite small, not to mention that the issue never even made it to a release.
> 
> 4) I agree with Tim that there's an issue in our test suite. Function-based 
> views give you the assumption that all HTTP methods will use the same entry 
> point into your view. You lose this assumption with class-based views but I 
> don't view this as a defect: to me, this is one of the big advantages of 
> class-based views. This probably means that we should audit Django's code and 
> add tests to make sure we cover all supported HTTP methods.
> 
> 
> Thanks,
> Baptiste
> 
> On 11/21/2016 08:11 PM, Markus Holtermann wrote:
>> Hi all,
>> 
>> As it turned out [1], due to their complexity, using class-based generic 
>> views for security-sensitive functionality can result in unintended 
>> behavior. Essentially, the reset token was only checked on GET requests, not 
>> on POST. This was due to the check being in `get_context_data()` (which is 
>> only called on GET but not POST except for invalid forms) and not higher up 
>> the stack. Validation could happen in the SetPasswordForm but doesn't really 
>> belong there either. The form is being used by the admin to allow superusers 
>> to change other users' password. Also, password resets could probably happen 
>> via other ways that want to leverage a form that doesn't require a token. In 
>> the end, from my perspective the check for the correct token does belong in 
>> the view.
>> 
>> While the reported issue was fixed [2] it raises the question if the added 
>> functionality of class-based generic views is worth the danger of shooting 
>> ourselves in the foot. I see the benefits of GCBVs. But given that the 
>> reported issue stayed unnoticed for 4 months makes me think that those views 
>> are not the best for these use cases and easily underpin the security 
>> functionality. Hence I suggest to revert the patch (including all additional 
>> features they gained) unless they are integrated in the function-based views 
>> and add guidelines on how to use class-based generic views for security 
>> sensitive feature.
>> 
>> This is the thread to get the discussion about this started.
>> 
>> One thing I want to suggest regardless if the class-based generic views are 
>> removed again or not, is to hold off the deprecation of the function-based 
>> views. This allows users who feel the same to not use class-based generic 
>> views without having deprecation warnings. At least until the next LTS 
>> release.
>> 
>> Furthermore, myself and Florian Apolloner, who discovered the issue, are 
>> leaning +0 to +1 on the revert of the class-based views.
>> 
>> Cheers,
>> 
>> Markus Holtermann
>> 
>> [1] 
>> https://www.djangoproject.com/weblog/2016/nov/21/passwordresetconfirmview-security-advisory/
>>  
>> 
>> [2] https://github.com/django/django/pull/7591 
>> -- 
>> 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 

Re: Password validation in Django revisited

[Erik Romijn]

Hi Alex, Carl,

On 22 Jun 2015, at 02:43, Carl Meyer  wrote:
> On 06/21/2015 06:17 PM, Alex Becker wrote:
>> With the PR merged, password validation applies to the SetPasswordForm
>> and the password changing forms, but not to the UserCreationForm or to
>> the creation of superusers. Is there a reason not to apply validation to
>> these as well?
> 
> Certainly makes sense to me to add validation to both of these. I missed
> it in review. Erik, is there a reason you didn't, or was it just an
> oversight?

No reason at all. I hadn’t even realised there was such a form. It seems
sensible to add it (along with a test), but I don’t have time to make the
patch currently.

Erik

-- 
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/960FE458-98D0-4B75-9178-2A5E4A96D3A4%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Erik Romijn]

Hi all,

The PR [1] has now been extended taking much of the feedback into account and 
adding docs and tests. I have also added a validator for common passwords, 
based on a list of 1000 most common passwords. So I think the PR is ready for 
another round of review - I’m sure there is still room for improvement. Only 
current open task is to add release notes.

We now have three validators, all enabled by default in new projects: the 
common password validator, a validator that simply checks whether the password 
meets a minimum length, and one that compares the password to the user’s 
attributes, such as their name or e-mail address. The latter has limits in it’s 
comparison - a more thorough method is provided, for example, by zxcvbn [2]. 
However, I think vendoring a Python port of zxcvbn is a little too much - I do 
intend to create a third party package with a validator that ties to zxcvbn.

There was a suggestion for a character class validator, e.g. requiring that the 
password contains digits or uppercase characters. I’m not very fond of that. 
Although quite common, I have strong doubts about whether it actually improves 
passwords: my impression is that requiring users to add a number will often 
mean they’ll add a 1 to the end, and requiring them to add an uppercase 
character will mean they uppercase the first character. If that is true, such a 
requirement would actually reduce password entropy, as one could assume that 
the last character of a password is almost always 1, etc. Unfortunately, I 
haven’t been able to find any research to support that (or the contrary), so I 
can’t back this up with anything solid.

For clarity, by default we do not enable any validators in existing projects 
when they upgrade, as that would be breaking backwards compatibility.

Erik

[1] https://github.com/django/django/pull/4276 
<https://github.com/django/django/pull/4276>
[2] https://github.com/dropbox/zxcvbn <https://github.com/dropbox/zxcvbn>

> On 14 Mar 2015, at 15:26, Erik Romijn  wrote:
> 
> Hi all,
> 
> Thanks for all the feedback. Good to see this seems to be heading in the 
> right direction. The suggestions make sense to me and I’ll work on those.
> 
> There were two particular design suggestions: instead of tying the validator 
> to the password field, tying this to the authentication backend, which would 
> prevent having to add a setting, and allow different security requirements 
> for different backends. Another suggestion was to add configurable password 
> fields instead, which could also include other functionality.
> 
> My concern with tying the validator to the auth backend instead, is that it 
> would mean there is absolutely no way to circumvent the validation, whereas 
> in the current scenario I’ve intentionally not included validation in 
> User.set_password() by default - but only in the user-facing elements. I 
> think it will be easier to get wider adoption of password validation, if we 
> still leave an opportunity open to avoid it in special cases. Also, I’m not 
> sure whether we could still easily and cleanly provide the appropriate help 
> text to the user.
> 
> If someone would want validation that depends on the auth backend, this is 
> possible with undocumented APIs. If my memory serves me right, the user 
> object that the validator has access to will have an attribute that 
> identifies the backend used to authenticate the user. The validator could 
> make different choices based on that, or even call a method on a backend. 
> That’s not with a currently documented API though.
> 
> Replaceable password fields are themselves interesting, but I think it would 
> be too limited for password validation in general. A specific wish was to 
> also be able to tie validation into a REST API, for example. The current 
> validator design allows trivial integration of a validator into absolutely 
> anything. Custom password fields are already not too hard - all you have to 
> do is create your own form, override the password fields and pass that form 
> to the appropriate views. It’s not even necessary to write your own views. We 
> could make that process simpler if the other benefits of custom password 
> fields are relevant enough, but I don’t think they’re the best design for the 
> validation problem.
> 
> Erik
> 
>> On 11 Mar 2015, at 09:52, Tino de Bruijn > <mailto:tin...@gmail.com>> wrote:
>> 
>> Hi Erik, I like the way this is going!
>> 
>> I do want to emphasise the point that Josh made: you have to be able to 
>> aggregate all ValidationErrors, otherwise things can become quite 
>> frustrating. (Try to change your Skype password and you know why...)
>> 
>> Tino
>> 
>> On Wed, Mar 11, 2015 at 1:44 AM, Josh Smeaton > <mailto:josh.smea...@gmail.com&

Re: Password validation in Django revisited

[Erik Romijn]

Hi all,

Thanks for all the feedback. Good to see this seems to be heading in the right 
direction. The suggestions make sense to me and I’ll work on those.

There were two particular design suggestions: instead of tying the validator to 
the password field, tying this to the authentication backend, which would 
prevent having to add a setting, and allow different security requirements for 
different backends. Another suggestion was to add configurable password fields 
instead, which could also include other functionality.

My concern with tying the validator to the auth backend instead, is that it 
would mean there is absolutely no way to circumvent the validation, whereas in 
the current scenario I’ve intentionally not included validation in 
User.set_password() by default - but only in the user-facing elements. I think 
it will be easier to get wider adoption of password validation, if we still 
leave an opportunity open to avoid it in special cases. Also, I’m not sure 
whether we could still easily and cleanly provide the appropriate help text to 
the user.

If someone would want validation that depends on the auth backend, this is 
possible with undocumented APIs. If my memory serves me right, the user object 
that the validator has access to will have an attribute that identifies the 
backend used to authenticate the user. The validator could make different 
choices based on that, or even call a method on a backend. That’s not with a 
currently documented API though.

Replaceable password fields are themselves interesting, but I think it would be 
too limited for password validation in general. A specific wish was to also be 
able to tie validation into a REST API, for example. The current validator 
design allows trivial integration of a validator into absolutely anything. 
Custom password fields are already not too hard - all you have to do is create 
your own form, override the password fields and pass that form to the 
appropriate views. It’s not even necessary to write your own views. We could 
make that process simpler if the other benefits of custom password fields are 
relevant enough, but I don’t think they’re the best design for the validation 
problem.

Erik

> On 11 Mar 2015, at 09:52, Tino de Bruijn  wrote:
> 
> Hi Erik, I like the way this is going!
> 
> I do want to emphasise the point that Josh made: you have to be able to 
> aggregate all ValidationErrors, otherwise things can become quite 
> frustrating. (Try to change your Skype password and you know why...)
> 
> Tino
> 
> On Wed, Mar 11, 2015 at 1:44 AM, Josh Smeaton  <mailto:josh.smea...@gmail.com>> wrote:
> Great stuff Erik. This will greatly simplify how we validate passwords!
> 
> One thing I'd like to note is that it is extremely frustrating when a form 
> fails validation with an error message, you fix that particular problem, and 
> you're given the next error message. Ideally, all validators would run and 
> spit out all of the error messages in one go. Then the user is given a chance 
> to correct all problems at once rather than a submit and hope game. I took a 
> look at the implementation and I don't think this is supported. Would it be 
> possible to aggregate all of the ValidationErrors?
> 
> Cheers
> 
> 
> On Monday, 9 March 2015 01:48:00 UTC+11, Erik Romijn wrote:
> Hello all,
> 
> I've taken another stab at 16860[1]: having a password validation/policy in 
> Django. I've made an initial simple PR[2] to show the approach I'd like to 
> use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, influencing 
> the later possibilities, which I'll try to outline below.
> 
> Users choosing awful passwords is a serious security issue. Although password 
> validation can only go so far - especially to the extent that we can 
> implement in Django itself - to me it seems part of our responsibility in 
> helping Django developers to build safer websites.
> 
> First, let me briefly describe my approach: we add a new setting to define 
> zero or more password validator classes. Optionally, a class can be provided 
> with custom arguments to it's constructor. Each validator class has a 
> help_text() method and a validate(password, user) method. The former produces 
> a translatable sentence to be included in the form field's help text. The 
> validate method validates a certain password, optionally taking the context 
> of a user into account and passes its judgement on the password. If a 
> validator considers a password insufficient, it raises a ValidationError.
> 
> This is tied to the validation and form field setup in SetPasswordForm and 
> AdminPasswordC

Re: Password validation in Django revisited

[Erik Romijn]

Hello Simon and Raphael,

Thanks for your input. I’ve adopted all your suggestions into the PR.

For the settings, I’ve now mirrored the TEMPLATE structure. I entirely agree 
that adding a new structure is an unnecessary burden on our users. I’m not too 
fond of Simon’s suggestion, as I’d like to have some basic configurability for 
each validator, without having to create an instance and store it somewhere 
yourself. That is still an option for advances customisation.

Erik

> On 08 Mar 2015, at 18:04, charettes  wrote:
> 
> Hi Erik,
> 
> This looks promising. I like how the validators can be chained and the whole 
> simplicity of the patch.
> 
> Here's some comments I also left on the PR;
> I think the settings should be name AUTH_PASSWORD_VALIDATORS since it's being 
> use by the auth contrib app;
> I would avoid mixing the backend and validators terminology. e.g 
> `get_password_validators` sounds like a more consistent name then 
> `get_password_backends`;
> I would either make `help_text` a property of rename the method to 
> `get_help_text`.
> Like Raphael I also think we should avoid introducing a new way of defining 
> settings. I suggest we use a list of path to instances of password validators 
> instead:
> 
> 
> AUTH_PASSWORD_VALIDATORS = [
> 'django.contrib.auth.password_validators.min_eight_chars_validator',
> ]
> 
> And document MinimumLengthPasswordValidator so you can create your own 
> instances and point the setting to it.
> 
> Simon
> 
> Le dimanche 8 mars 2015 10:48:00 UTC-4, Erik Romijn a écrit :
> Hello all,
> 
> I've taken another stab at 16860[1]: having a password validation/policy in 
> Django. I've made an initial simple PR[2] to show the approach I'd like to 
> use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, influencing 
> the later possibilities, which I'll try to outline below.
> 
> Users choosing awful passwords is a serious security issue. Although password 
> validation can only go so far - especially to the extent that we can 
> implement in Django itself - to me it seems part of our responsibility in 
> helping Django developers to build safer websites.
> 
> First, let me briefly describe my approach: we add a new setting to define 
> zero or more password validator classes. Optionally, a class can be provided 
> with custom arguments to it's constructor. Each validator class has a 
> help_text() method and a validate(password, user) method. The former produces 
> a translatable sentence to be included in the form field's help text. The 
> validate method validates a certain password, optionally taking the context 
> of a user into account and passes its judgement on the password. If a 
> validator considers a password insufficient, it raises a ValidationError.
> 
> This is tied to the validation and form field setup in SetPasswordForm and 
> AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
> User.set_password(). However, I intentionally did not include that step, as I 
> feel this validation should primarily take place on the user frontend site 
> with forms. This mirrors the way we typically handle this in Django. Should 
> someone feel different, and want to tie this to set_password() as well, this 
> is possible with a custom user object. Tying this validation into any other 
> place is also trivial: just adding a single line.
> 
> I decided not to go for standard Django validators, as I felt this would 
> offer insufficient flexibility and configurability - as was already raised in 
> previous discussions on this issue.
> 
> In the ticket, Shai described a few particular goals for this feature:
> 
> - Informing the user of the various password requirements: this is possible 
> by each validator providing a description, which can be dependent on it's 
> configuration, of it's requirements. Independent sentences from different 
> validators are now concatenated, an approach which will not always yield the 
> prettiest language.
> - Allowing policies to chain together smoothly: multiple validators can be 
> run sequentially, stopping after the first failure.
> - Provide flexibility for complex requirements (some may include their own 
> models): this is entirely possible within the design.
> - Backwards compatibility: the default setting is to have no validators, 
> which means no change and no modifications in help text. I do suggest we 
> include some reasonable defaults in the standard project template.
> - Javascript validation assistance or HTML5 support: n

Password validation in Django revisited

[Erik Romijn]

Hello all,

I've taken another stab at 16860[1]: having a password validation/policy in 
Django. I've made an initial simple PR[2] to show the approach I'd like to use 
- no tests or documentation yet, the example validators are not very nice, 
possibly bad naming, etc. But this should be sufficient to show how I would 
like to tackle this. There's quite a few decisions to take, influencing the 
later possibilities, which I'll try to outline below.

Users choosing awful passwords is a serious security issue. Although password 
validation can only go so far - especially to the extent that we can implement 
in Django itself - to me it seems part of our responsibility in helping Django 
developers to build safer websites.

First, let me briefly describe my approach: we add a new setting to define zero 
or more password validator classes. Optionally, a class can be provided with 
custom arguments to it's constructor. Each validator class has a help_text() 
method and a validate(password, user) method. The former produces a 
translatable sentence to be included in the form field's help text. The 
validate method validates a certain password, optionally taking the context of 
a user into account and passes its judgement on the password. If a validator 
considers a password insufficient, it raises a ValidationError.

This is tied to the validation and form field setup in SetPasswordForm and 
AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
User.set_password(). However, I intentionally did not include that step, as I 
feel this validation should primarily take place on the user frontend site with 
forms. This mirrors the way we typically handle this in Django. Should someone 
feel different, and want to tie this to set_password() as well, this is 
possible with a custom user object. Tying this validation into any other place 
is also trivial: just adding a single line.

I decided not to go for standard Django validators, as I felt this would offer 
insufficient flexibility and configurability - as was already raised in 
previous discussions on this issue.

In the ticket, Shai described a few particular goals for this feature:

- Informing the user of the various password requirements: this is possible by 
each validator providing a description, which can be dependent on it's 
configuration, of it's requirements. Independent sentences from different 
validators are now concatenated, an approach which will not always yield the 
prettiest language.
- Allowing policies to chain together smoothly: multiple validators can be run 
sequentially, stopping after the first failure.
- Provide flexibility for complex requirements (some may include their own 
models): this is entirely possible within the design.
- Backwards compatibility: the default setting is to have no validators, which 
means no change and no modifications in help text. I do suggest we include some 
reasonable defaults in the standard project template.
- Javascript validation assistance or HTML5 support: not implemented currently, 
but this could be added in a similar way as help texts.
- Prevent using email, username or other user attributes as (part of) 
passwords: where possible, the user object is passed to the validator. There's 
a (not pretty) example of this in the PR.
- Prevent reuse of old passwords: it is possible in the design for a validator 
to store all passwords it saw. I have doubts on whether this would be a good 
approach though.

So I think this design makes it simple to have sane defaults for new projects, 
extensive configurability while keeping simple scenarios simple to configure, 
and easy extensibility with third party password validators (zxcvbn comes to 
mind). I'd love to hear any feedback and ideas you may have.

Erik


[1] https://code.djangoproject.com/ticket/16860
[2] https://github.com/django/django/pull/4276

-- 
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/DC7E0945-5FC9-43CA-97C5-FE5872A05DE1%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CSRF cipher in xor + base64 or Vignere cipher

[Erik Romijn]

Hello,

In the context of a one time pad on the CSRF token, I don’t see a security 
advantage to either cipher here. If I read correctly, the argument for Vignere 
is that it can already produce output suitable for inclusion in form values, 
not requiring base64 encoding of the one time pad.

I’ve looked up the current implementations that have been contributed:
Here’s the XOR+base64 implementation:
https://github.com/django/django/compare/66285eb2a7a6fb3e6ec0eec0bbc15a5e94215872#diff-a3be722ce2831a8d11438021d44cedf1R62
 

And the Vignere implementation:
https://github.com/django/django/pull/1477/files#diff-a3be722ce2831a8d11438021d44cedf1R40
 


Though the Vignere implementation means that base64 is not required and is 
significantly shorter, it seems considerably more complex and error prone. I 
can’t instantly see whether this implementation is correct. The XOR+base64 
implementation, on the other hand, is straight forward and obvious. Therefore, 
if the current implementations are a proper measure for the complexity of 
implementing either option, XOR+base64 is my strong preference. Slightly more 
work, but substantially simpler, reducing the risk of overlooked implementation 
errors.

Erik

> On 07 Mar 2015, at 13:31, Asif Saifuddin  wrote:
> 
> Hi,
> 
> Just start working on this ticket https://code.djangoproject.com/ticket/20869
> 
> wondering what should be the preferred way ?
> 
> using XOR or Vignere Cipher?
> 
> 
> Reagrds
> 
> --
> 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/3d23b87e-c153-4035-a838-331d5bc9cd1d%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/10CE5813-C1DA-4231-8721-36A2AEEB8748%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Place on a server

[Erik Romijn]

Hello,

The best place to get answers to your questions is the django-users email list, 
mailto:django-developers@googlegroups.com>> - the web interface is 
>.

If you decide to ask on that list, please add more details on what exactly you 
are trying to accomplish, and where you’re currently stuck. For example, if 
you’re getting any error messages, be sure to include them in your mail. I’m 
afraid the information you’re currently giving makes it near impossible for 
someone to help you narrow this issue down.

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net 
 - but also there, ensure that you clearly explain 
what you are trying to do, how you are trying to do this, and what issues 
you’re running into.

I hope that helps,

Erik

> On 03 Mar 2015, at 22:50, Ch. APPerone  wrote:
> 
> Who can help me to place www.demoafspraaktotaal.nl on the server We have 
> problems with de dependencies!!
> 
> --
> 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/e2035007-66e6-4956-acbf-354a2e0fbf6c%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/8DD22E93-4464-488A-968A-50C3A6530F5A%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Erik Romijn]

On 03 Feb 2015, at 16:44, Jon Dufresne  wrote:
> However some URLs are accessed by a unique URL
> containing a nonce without a login. Login is not an option for these
> URLs. Sharing this URL is considered very bad and I would like to
> avoid it happening unintentionally.

I'm not following this: to prevent this case, you are actively
instructing all your users to disable referer headers in their browsers?
If not, how are you controlling what referrers your users send?

URLs without login, which contain a secret nonce, are indeed sensitive
to the nonce leaking through the referer. Dropbox ran into this a
while ago:
https://blog.dropbox.com/2014/05/web-vulnerability-affecting-shared-links/

This also affected Evernote for some time. The common resolution seems
to be not to disable referer headers, which is a client-side issue, but
to mask it by sending all external links through a specific URL first
without the nonce, which works as a simple redirector.

Far from ideal, especially when dealing with more complicated links like
when sharing office documents. But it seems to work for Dropbox and
Evernote. You'll notice for example that when viewing a PDF on Dropbox,
you're not using your in-browser PDF viewer but Dropbox' custom viewer,
which I imagine also modifies all external links.

Erik

-- 
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/1AFE30EE-237E-4993-A29D-4D13F179FD16%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 'Manager isn't available; User has been swapped for 'register.User''

[Erik Romijn]

Hello Ajay,

> On 20 Nov 2014, at 06:20, Ajay Kumar  wrote:
> 
> hi guys. I'm in a django project , i tried to customize the user table model 
> and tried to add a field gender in it and added success fully ,as per the 
> instruction i followed changes and got gender field in it.but when i tried to 
> save it gives the error that 'Manager isn't available; User has been swapped 
> for 'register.User'' guys give me the solution for this

Your best bet for an answer is the django-users email list, 
 - the web interface is 
. 

This django-developers email list is only for the discussion of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

Good luck!

cheers,
Erik

-- 
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/B47B42A8-05A5-4FC9-AA15-24B3DAE9495E%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

[Erik Romijn]

I think it would also be a great improvement if we all adopted a standard 
response for these kind of mails - because no matter what we do, some will 
still end up here.

Almost entirely based on Daniele's previous responses, how about we use:

> The best place to get answers to your questions is the django-users email 
> list,  - the web interface is 
> . 
> 
> The list you've posted to is django-developers, an email list is for the 
> discussion of the development of Django itself.
> 
> You might also find helpful the #django IRC channel on irc.freenode.net.
> 
> I hope that helps,

This focuses first on helping them get to the right place, with easily readable 
language, and then explains their error in a friendly way. In the past, we've 
occasionally sent somewhat more harsh replies, focusing more on how they did 
something wrong. Although I'm sure such replies were absolutely sent with the 
best intentions, it's not a pleasant first experience.

Not sure what the best place is to keep this template easily accessible for 
anyone though. The wiki might be the most suitable.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/07EC2CEB-A0AC-4624-874C-6D8FBD9D594C%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

[Erik Romijn]

I strongly agree, *if at all possible*. What I'm saying is that HSTS can break 
so much, even after you revert everything you've changed, that we should make 
sure users have a rough idea of determining when it is possible. Please deploy 
HSTS everywhere, but only after you've thought through what you're actually 
affecting and for how long.

We can be much more brief in recommendations regarding X-Frame-Options or the 
secure flag on cookies, because even in if it breaks everything, you can just 
revert back and everything will work again. And you'll only break the site 
you're working on.


On 01 Sep 2014, at 18:34, Donald Stufft  wrote:

> Eh, I think we should advise people to switch on HSTS and with 
> includeSubdomains if at all possible. 
> 
>> On Sep 1, 2014, at 1:31 PM, Erik Romijn  wrote:
>> 
>> Hi all,
>> 
>> I think finally integrating django-secure is a great step. Making a separate 
>> deploy check also makes sense to me. However, I think we should be very 
>> cautious with pushing people to enable HSTS.
>> 
>> Some of our security headers can cause things to break. For example 
>> redirecting to SSL when your HTTPS is broken, will break your site. Enabling 
>> strict X-Frame-Options when you do use external iframes, will break your 
>> site. However, if you then fix the setting, everything will work again. 
>> Inconvenient, but easy to recover. Also, these effects are limited to the 
>> Django site you are working on.
>> 
>> If I were hosting a Django site on example.com, and enable HSTS with 
>> includeSubdomains and a lifetime of 6 months, as seems to be common now, I 
>> might not only break my own site, but also every other side under 
>> example.com. Upon discovering the error it can be corrected, but not before 
>> a unknown set of users has memorized that all of example.com and any site 
>> under it must use HTTPS.
>> 
>> So, although I encourage anyone to enable HSTS, we should not recommend 
>> people to just "switch it on". They should be well aware of the consequences 
>> as it can affect an unknown set of users beyond their Django site, long 
>> after the change has been reverted. The possible seriousness should be 
>> reflected in any encouragement we make for HSTS to be enabled.
>> 
>> Erik
>> 
>> 
>> On 28 Aug 2014, at 02:25, Tim Graham  wrote:
>> 
>>> After I wrote the original email, I found #17101 which is where the 
>>> checkdeploy idea came from. We can just close that ticket (or modify it) if 
>>> we decide on a different solution. It was created before the checks 
>>> framework was merged and I agree a separate command may not be ideal, 
>>> although it may make the implementation slightly easier. I'll look into 
>>> using DEBUG tomorrow. One issue is that we don't want these checks run 
>>> during testing (and DEBUG is often False there). Maybe if these checks are 
>>> registered with something like checks.register(foo, deploy=True), we can 
>>> skip any checks registered like that during testing. I'll have to see if 
>>> there's some way to make this work with 'manage.py test' as well as with 
>>> 3rd party test runners. If we had a separate checkdeploy command, avoiding 
>>> this problem might be somewhat easier.
>>> 
>>> I am fine with putting it in core instead of contrib. That just means we 
>>> need to figure out what to do about settings since we cannot put them on an 
>>> AppConfig. Assuming we don't want to add them as normal settings, we may be 
>>> able to use the approach proposed on this mailing list for the CSRF 
>>> settings -- using attributes on the middleware class (PR). In that case, 
>>> the check could work by iterating through MIIDDLEWARE_CLASSES until it 
>>> finds a subclass of SecurityMiddleware and then check the attributes 
>>> (settings) on that class. I will look into this approach tomorrow.
>>> 
>>> Thanks for the feedback!
>>> 
>>> On Wednesday, August 27, 2014 8:47:26 PM UTC-4, Curtis Maloney wrote:
>>> For what it's worth, I agree with Russ.
>>> 
>>> Having security as an optional extra [which is how it will look to 
>>> outsiders] is a bad look for Django, and certainly doesn't fit with the 
>>> "Secure by default" philosophy.
>>> 
>>> --
>>> Curtis
>>> 
>>> 
>>> On 28 August 2014 10:34, Russell Keith-Magee  wrote:
>>> Hi Tim,
>>> 
>>> On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham  wrote:

Re: integrating django-secure

[Erik Romijn]

Hi all,

I think finally integrating django-secure is a great step. Making a separate 
deploy check also makes sense to me. However, I think we should be very 
cautious with pushing people to enable HSTS.

Some of our security headers can cause things to break. For example redirecting 
to SSL when your HTTPS is broken, will break your site. Enabling strict 
X-Frame-Options when you do use external iframes, will break your site. 
However, if you then fix the setting, everything will work again. Inconvenient, 
but easy to recover. Also, these effects are limited to the Django site you are 
working on.

If I were hosting a Django site on example.com, and enable HSTS with 
includeSubdomains and a lifetime of 6 months, as seems to be common now, I 
might not only break my own site, but also every other side under example.com. 
Upon discovering the error it can be corrected, but not before a unknown set of 
users has memorized that all of example.com and any site under it must use 
HTTPS.

So, although I encourage anyone to enable HSTS, we should not recommend people 
to just "switch it on". They should be well aware of the consequences as it can 
affect an unknown set of users beyond their Django site, long after the change 
has been reverted. The possible seriousness should be reflected in any 
encouragement we make for HSTS to be enabled.

Erik


On 28 Aug 2014, at 02:25, Tim Graham  wrote:

> After I wrote the original email, I found #17101 which is where the 
> checkdeploy idea came from. We can just close that ticket (or modify it) if 
> we decide on a different solution. It was created before the checks framework 
> was merged and I agree a separate command may not be ideal, although it may 
> make the implementation slightly easier. I'll look into using DEBUG tomorrow. 
> One issue is that we don't want these checks run during testing (and DEBUG is 
> often False there). Maybe if these checks are registered with something like 
> checks.register(foo, deploy=True), we can skip any checks registered like 
> that during testing. I'll have to see if there's some way to make this work 
> with 'manage.py test' as well as with 3rd party test runners. If we had a 
> separate checkdeploy command, avoiding this problem might be somewhat easier.
> 
> I am fine with putting it in core instead of contrib. That just means we need 
> to figure out what to do about settings since we cannot put them on an 
> AppConfig. Assuming we don't want to add them as normal settings, we may be 
> able to use the approach proposed on this mailing list for the CSRF settings 
> -- using attributes on the middleware class (PR). In that case, the check 
> could work by iterating through MIIDDLEWARE_CLASSES until it finds a subclass 
> of SecurityMiddleware and then check the attributes (settings) on that class. 
> I will look into this approach tomorrow.
> 
> Thanks for the feedback!
> 
> On Wednesday, August 27, 2014 8:47:26 PM UTC-4, Curtis Maloney wrote:
> For what it's worth, I agree with Russ.
> 
> Having security as an optional extra [which is how it will look to outsiders] 
> is a bad look for Django, and certainly doesn't fit with the "Secure by 
> default" philosophy.
> 
> --
> Curtis
> 
> 
> On 28 August 2014 10:34, Russell Keith-Magee  wrote:
> Hi Tim,
> 
> On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham  wrote:
> I've started tackling one of the ideas that's been on our GSoC ideas
> page for a couple years now: integrating django-secure. I chatted with
> Carl about the idea and he's onboard. There are a couple of design
> decisions we'll need to make.
> 
> +1 to the idea. It was part of Chris' original proposal; we just didn't get 
> around to it with the available time.
>  
> 1. How to integrate django-secure with the checks framework
> django-secure essentially implements its own checks framework (which
> predates the one in Django). The tricky part is that django-secure's
> checks are not ones that generally should pass on a
> development instance; they're checks that only make sense to run on a
> production server (or at least against a production settings file).
> I'm thinking to have some way to skip these new checks by default and
> run them only when requested (e.g. manage.py check secure
> --settings=prod_settings). Other options include an entirely separate
> command like django-secure implements (curently called checksecure),
> but perhaps could be called checkdeploy and eventually extended with
> other checks that are relevant only in production. Idea/insight from
> those more familiar with the checks framework (Chris, Russ), would be
> welcome.
> 
> Generally, I'd be opposed to the idea of Yet Another Command to run checks - 
> if you make it optional, it won't get run, and this is something we want to 
> be forced in front of everyone.
> 
> We use DEBUG as a proxy for "In Production" in other locations in the 
> codebase - e.g., whether ALLOWED_HOSTS checks are run. If we were to 
> supplement that with a --product

Re: on type-specific input fields

[Erik Romijn]

Hello,

I've had another look at this. The novalidate attribute on the form for URL and 
email fields indeed disables the validation in both Chrome and Safari. For 
number fields, I can reproduce Patrick's test: Safari will still silently drop 
the value.

So, for URL and email fields, this issue is resolved by setting novalidate on 
the form. I think we should document a recommendation for users to add this 
attribute to their forms, and change the forms in the admin to always include 
the novalidate attribute, as Bruno suggested.

This does not resolve the issue of Safari silently discarding invalid numbers. 
I don't see a way to resolve that, other than to revert to the text field. 
Perhaps this is a Safari bug. I haven't managed to find a standard on what 
browsers should be doing in this case, but this behaviour seems awful. But even 
if it is a Safari bug, that wouldn't fix the issue for a while anyways. 
Overall, I'd rather go for the partial novalidate solution for now, than do 
nothing at all.

cheers,
Erik


On 23 Jul 2014, at 13:15, patrickk  wrote:

> I'm not so sure "novalidate" is a viable solution.
> 
> If you have a DecimalField and you enter "xxx" this is what happens ...
> 
> a) With "novalidate" added to the form:
> The value is being removed from the field and the form is being saved (tested 
> with Firefox and Safari).
> 
> b) Without "novalidate":
> The value is being removed with Safari. There is an error message with 
> Firefox.
> 
> c) Expected behaviour:
> The form ist not being saved and I get an error message with the field.
> 
> Best,
> Patrick
> 
> 
> Am Mittwoch, 23. Juli 2014 12:15:12 UTC+2 schrieb Aymeric Augustin:
> "novalidate" would solve the problem as far as the admin is concerned. 
> 
> I wasn't very enthusiastic about switching to the HTML5 input types so early; 
> now that we have them, I'd rather live with them than remove them, probably 
> to reintroduce them in a later release. 
> 
> -- 
> Aymeric. 
> 
> 
> 
> On 23 juil. 2014, at 11:47, Bruno Renié  wrote: 
> 
> > Hi Erik, 
> > 
> > I think a more elegant solution than rolling back to TextInput would 
> > be to promote/document the use of the "novalidate" attribute. In a 
> > nutshell, '' disables client-side 
> > validation, letting users submit forms regardless of the client 
> > validation logic while still taking advantage of the HTML5 input 
> > types. 
> > 
> > Browsers support doesn't seem to be an issue as browsers which don't 
> > support that attribute (iOS, Android browsers) don't prevent form 
> > submission at all so they already have a "" behavior. 
> > 
> > Cheers, 
> > Bruno 
> > 
> > On Wed, Jul 23, 2014 at 11:34 AM, Erik Romijn  wrote: 
> >> Hello all, 
> >> 
> >> Since Django 1.6, the Django form fields for URLs, numbers and email 
> >> addresses make use of widgets that use type-specific input fields in their 
> >> HTML rendering. So instead of rendering them as , they 
> >> now have type="url", type="number" and type="email". This has upsides: for 
> >> example, an email field will cause an iPhone to display the 
> >> email-optimized keyboard. 
> >> 
> >> However, in #23075[1] sehmaschine raised an important issue: this also 
> >> causes browsers to apply their own validation to these fields. This causes 
> >> a number of issues: 
> >> 
> >> * The validation code used by the browser may not match that used in 
> >> Django. For example, URLField will accept "example.com", but Chrome's 
> >> validation for type="url" will reject it. Safari on the other hand, does 
> >> accept it. So there are two validation steps, which may not be equal, and 
> >> which may differ per browser. 
> >> 
> >> * Error behaviour of browsers is inconsistent. Chrome renders it's own 
> >> unstylable error message. Safari, according to comment 3, will simply 
> >> remove invalid values, which is a usability disaster in itself, but 
> >> avoidable if the field was type="text" as then the form validation would 
> >> detect the invalid value, reject it, and provide a proper error message. 
> >> 
> >> * Validation timing becomes inconsistent. In the traditional form 
> >> validation flow, the user would submit the form, see any errors, and 
> >> submit again. With these fields, some of the validation happens before 
> >> submit, but some does no

Re: Requiring GitHub login for actions on Trac

[Erik Romijn]

Thank you for working on this, Aymeric. I am definitely +1 on moving to 
GitHub as sole authentication provider for trac.

We could argue about this forever. In the mean time the spam will pile
up, core developers will have to spend time deleting all of it, and
eventually we'd come to a plan which will never be executed because
nobody has enough time to build the convoluted end result.

Using GitHub makes sense as it's very likely a new contributor already
has a GitHub account (and if not, creating an account is useful for
much more than just Django), and many actions of contributing to Django
already tie closely to GitHub - even though you can still avoid it if
you really insist.

I have no strong feelings about having trac and GitHub authentication
both available. If we can make it work, it makes sense to allow it, but
I can see your point regarding technical issues that may have.

Most of all, let's be pragmatic about it and stop the spam, with the
added benefit of lowering the boundary for new contributors.

Erik

On 07 Aug 2014, at 08:46, Aymeric Augustin  
wrote:

> To be clear, I have a working implementation of GitHub OAuth that I can
> activate as soon as we reach a consensus.
> 
> 
> 
> On 7 août 2014, at 02:43, Ben Finney  wrote:
> 
>> −1. I am happy to agree to Django's BTS terms of use, not GitHub's.
>> Please don't make the former depend on the latter.
> 
> I didn’t know our Trac installation had terms of use. So, are you
> volunteering to jump in and delete spam as it comes in? Or do you
> have an alternative proposal?
> 
> 
> 
> On 7 août 2014, at 02:47, Shai Berger  wrote:
> 
>> Today, it is possible to contribute to the Django project without a 
>> Github account. I would like this to remain the case.
> 
> This is possible but in a limited capacity. To be honest, I think that
> ship sailed when we moved to GitHub. We would have also moved
> issues there if GitHub’s tools were usable.
> 
> 
> 
> On 7 août 2014, at 02:58, Andre Terra  wrote:
> 
>> Most importantly, how would Django as a project benefit from this
>> choice other than reducing minimal spam?
> 
> Did you just ask “how would Django as a project benefit from having
> core devs work on committing patches rather than fighting spam”?
> 
> If you don’t already have a djangoproject.com account, you’re likely to
> give up on reporting a small bug just because it’s too complicated to
> log in. Considering our target demographic, GitHub OAuth would
> eliminate this problem.
> 
> Also, if you’re trying to report a bug anonymously, you’re likely to be
> unable to pass the CAPTCHA, and also be unable to report it, because
> you’re still getting blocked by the CAPTCHA. See complaints:
> https://code.djangoproject.com/search?q=captcha&noquickjump=1&ticket=on
> 
> Finally, to be honest, I’d rather adjust Django’s tools to enthusiastic
> beginners than grumpy freedom extremists who refuse to use GitHub.
> 
>> A better solution would be to strengthen what it means to have an identity
>> on djangoproject.com. Rather than restricting user actions to Trac, we
>> could motivate users to create something like a Django profile which would
>> be used for Trac (among may other uses)
> 
> We already have that: https://www.djangoproject.com/~aaugustin/
> 
>> and could later be linked to any OAuth providers, including but not limited
>> to GitHub.
> 
> We don’t have that.
> 
>> TL;DR Identity on djangoproject.com, Authentication linked to multiple OAuth,
>> Authorization in Trac.
> 
> Are you volunteering to do this work, and if so, when will it be done?
> 
>> I hope that idea makes sense. I may be just babbling nonsense.
> 
> 
> I’m sorry, but ideas don’t matter nearly as much as execution here.
> We just need working tools — nothing fancy.
> 
> 
> 
> On 7 août 2014, at 02:59, Josh Smeaton  wrote:
> 
>> is it easy enough to support github oauth + the current trac auth 
>> concurrently?
>> If a user chooses to go through the harder path, that's fine.
> 
> It may be doable to provide two authentications endpoints, like /login and
> /login/github. Trac just looks at REMOTE_USER and creates a session that
> lasts until you logout. I’ll look into it.
> 
> That solves the “GitHub is evil, I don’t want to touch their bytes with a six
> foot pole” problem, but only half of the username mismatch problem. You
> can keep using your djangoproject.com username is you wish, but if
> someone else owns the same username on GitHub, they can impersonate
> you e.g. https://github.com/shai / https://www.djangoproject.com/~shai/.
> 
> That said, if you aren’t logged in, you can type anything you want in Trac's
> “Your username or email” field. It provides identification, not 
> authentication.
> This has never been a problem in the past. So I don’t think we’ll run into
> too much trouble with usernames in general.
> 
> The only part where Trac usernames are used for authentication is access
> control, which only applies to people who have special permissions.
> 
> -- 
> Ayme

Re: Updating the organization of the Django Project

[Erik Romijn]

+1

Thanks for all the work on this.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/F7D0A20D-6BBF-4D1E-A43E-A1F5D5ECC72B%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

on type-specific input fields

[Erik Romijn]

Hello all,

Since Django 1.6, the Django form fields for URLs, numbers and email addresses 
make use of widgets that use type-specific input fields in their HTML 
rendering. So instead of rendering them as , they now have 
type="url", type="number" and type="email". This has upsides: for example, an 
email field will cause an iPhone to display the email-optimized keyboard.

However, in #23075[1] sehmaschine raised an important issue: this also causes 
browsers to apply their own validation to these fields. This causes a number of 
issues:

* The validation code used by the browser may not match that used in Django. 
For example, URLField will accept "example.com", but Chrome's validation for 
type="url" will reject it. Safari on the other hand, does accept it. So there 
are two validation steps, which may not be equal, and which may differ per 
browser.

* Error behaviour of browsers is inconsistent. Chrome renders it's own 
unstylable error message. Safari, according to comment 3, will simply remove 
invalid values, which is a usability disaster in itself, but avoidable if the 
field was type="text" as then the form validation would detect the invalid 
value, reject it, and provide a proper error message.

* Validation timing becomes inconsistent. In the traditional form validation 
flow, the user would submit the form, see any errors, and submit again. With 
these fields, some of the validation happens before submit, but some does not. 
This can be confusing for users.

The workaround is to override the widget in ModelForms or admin forms, and 
force it to forms.TextInput().


If we leave the situation as is, developers may unexpectedly find that their 
users may get validation errors which are different from all others in content, 
style and timing (and possibly language), whose criteria do not match other 
validation steps for the same data, and all this will work differently in 
different browsers. With the Safari behaviour of simply ignoring invalid 
values, mentioned by sehmaschine in the ticket, this becomes even more serious.

Therefore, as much as I like using the correct field types, I think their 
issues outweigh the current benefits. I propose that we change all relevant 
fields to use forms.TextInput() as their default widget, still allowing a 
developer to override this with a specific widget if they do want to use 
type="number". Ideally, considering the potential impact, I'd still like to see 
this changed in 1.7, although I realise it's very very late for that.

In any case, I thought this might be controversial enough to first bring it up 
on this list.

cheers,
Erik


[1] https://code.djangoproject.com/ticket/23075

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/6E0F05BE-D767-44B1-9626-3811758C9D31%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

problem with testing for DeprecationWarning

[Erik Romijn]

Hello,

I've started working on #22130, the deprecation of fix_ampersands, but I'm 
running into some trouble with building the tests. I imagine there's someone on 
this list with more experience in this, who might be able to help.

My current patch is at 
https://github.com/erikr/django/compare/deprecate-fix-ampersands?expand=1

The issue is that when running the full test suite, my test to assert that 
warnings are being issued, fails:
==
FAIL: test_fix_ampersands (utils_tests.test_html.TestUtilsHtml)
--
Traceback (most recent call last):
  File "/Users/erik/dev/django/tests/utils_tests/test_html.py", line 157, in 
test_fix_ampersands
self.assertEqual(len(w), 18)
AssertionError: 0 != 18

--

Curiously, when I run this test independently, or when I run utils_tests 
independently, this test succeeds. Perhaps there is some interaction with other 
tests in the suite?

Direct link to the test in question:
https://github.com/erikr/django/compare/deprecate-fix-ampersands?expand=1#diff-adcabff46f848a5dece079381c6d9485R134

I've mostly looked at existing tests for deprecation for my modifications of 
this one - perhaps there's something I've overlooked that might cause my 
problem. If anyone could have a look, it would be much appreciated :)

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/AE870DA8-469E-4C5D-B0F6-200A8052B46E%40solidlinks.nl.
For more options, visit https://groups.google.com/groups/opt_out.

Accelerated deprecation of fix_ampersands and clean_html

[Erik Romijn]

Dear all,

I would like to propose the accelerated deprecation of the
fix_ampersands built-in template filter, because in all use cases, it
either simply does not work, or stimulates the user to create security
vulnerabilities.

In addition, I would like to deprecate django.utils.html.clean_html. This 
is the only code in Django that uses fix_ampersands, and it's use is 
rather unclear. This function is not documented.

I have written a more extensive rationale on the ticket created for this:
https://code.djangoproject.com/ticket/22130

Are there any concerns or suggestions?

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/C8ED78A5-2486-411F-AA93-4D147F5C6169%40solidlinks.nl.
For more options, visit https://groups.google.com/groups/opt_out.

Django sprint in Amsterdam, The Netherlands, Feb 22/23

[Erik Romijn]

Hello all,

I’m very happy to announce that a two-day Django sprint will take place on 
February 22-23 in Amsterdam, Netherlands. This event is organized by the Dutch 
Django Association. Sign up and more information on: 
http://www.meetup.com/dutch-django-assocation/events/155766972/

The venue is the office of TravelBird, who have offered to be our host, in the 
center of Amsterdam. The sprint will start on Saturday, February 22rd at 10:00 
CET and and finish on Sunday, February 23 around 22:00 CET.

With the help of the Django Software Foundation and Dutch Django Association we 
will have two core developers on site: Baptiste Mispelon and Daniele Procida. 
Daniele will also be doing his famed “Don’t be afraid to commit” workshop, 
which will take people new to contributing to Django through the entire 
contribution process with real tickets. So please don’t hesitate to join even 
if you’ve never contributed to Django before.

If you’re unable to come to Amsterdam, you're welcome to contribute to the 
sprint online. Sprinters and core developers will be available in the 
#django-sprint IRC channel on FreeNode.

We hope you can join us and help make the sprint as successful as possible! If 
you have any further questions, don't hesitate to contact me directly.

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/8ADACF1C-61EA-4D30-BFDA-757B45B78B57%40solidlinks.nl.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New to Django - Question: All registered users to post content...

[Erik Romijn]

Hello Stephen,

On 06 Jan 2014, at 02:48, Retnuh  wrote:
> I am new to Django (converted from Drupal) and trying to learn Django first 
> before I dive into converting my site over from HTML,CSS and JS to use Django 
> and Python…

Your best bet for an answer is the django-users email list, 
 - the web interface is 
. 

This django-developers email list is only for the discussion of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

Good luck!

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/D1EACBE6-BEC3-47D4-A5DF-4633BF01C01C%40solidlinks.nl.
For more options, visit https://groups.google.com/groups/opt_out.

Re: User created objects

[Erik Romijn]

Hello Ideo,

On Oct 20, 2013, at 9:11 AM, Ideo Rex  wrote:
> I'm relatively new to Django. So I have a working (local) web application. I 
> can create new model objects from the admin site, but I would like my users 
> to be able to create their own objects and save them to the database. I'm 
> really confused on the over arching process on how this is down and I would 
> appreciate it if someone could lead me in the correct direction.

Your best bet for an answer is the django-users email list, 
 - the web interface is 
. 

The django-developers email list is only for the discussion of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

Good luck!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/7159CAC1-056C-4940-8AE2-09F89AB6FB3A%40solidlinks.nl.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecating ipaddressfield

[Erik Romijn]

Hi Michael,

On Aug 25, 2013, at 6:27 PM, Michael Manfre  wrote:
> The code on master doesn't agree with your statement about mysql and sqlite.
> sqlite - 
> https://github.com/django/django/blob/master/django/db/backends/sqlite3/creation.py#L26

SQLite doesn't actually have a CHAR type - it will consider both of these 
columns to be the TEXT type: http://www.sqlite.org/datatype3.html

> mysql - 
> https://github.com/django/django/blob/master/django/db/backends/mysql/creation.py#L23

You are correct - I seem to have remembered incorrectly.

>> The storage size required for a varchar is the same for any length from 1 to 
>> 255: one byte to store the content length, and then the bytes of the 
>> content. So storage size or performance is not affected. On Oracle, it's 
>> VARCHAR2(15) vs VARCHAR2(39) - I assume they store it similar to MySQL.
>> 
> I don't think that is true for all databases, nor should Django make that 
> type of assumption. Unless I've misunderstood how MSSQL works, which is 
> possible, it only adds a few bytes of overhead to the actual data.

MSSQL is not a supported database in Django itself, so I have no idea, or 
control over, how the (Generic)IPAddressField types are stored in there. Let 
alone what the differences in storage size might be.
 
>> In other words, if you replace an IPAddressField with a 
>> GenericIPAddressField and store the same data, storage size or database 
>> performance is not affected, even though the column type may need to be 
>> changed.
>> 
> This is probably true for some databases, but not guaranteed to be true for 
> all.

With your correction on the MySQL datatypes, this is indeed not true for MySQL. 
It would introduce an overhead of 24 bytes. However, countering that are 
several good reasons to proceed with deprecation.

IPAddressField has no model validation, which means that it will often allow 
storing IPv6 addresses. This may work, or may result in silent truncation or an 
error, depending on the database backend and it's settings. Should storing the 
IPv6 address work, then trying to edit that object through a ModelForm later, 
e.g. in the admin, will fail. These limitations are in no way obvious to any 
IPAddressField user.

IPv6 addresses are not just encountered by users that consciously make a 
decision to support IPv6, and therefore would look deeper into support in 
fields. It is fairly common to see IPv6-mapped IPv4 addresses, like 
::::192.0.2.1, in REMOTE_ADDR. IPAddressField may truncate these silently 
or fail the query.

As Aymeric points out, it is just confusing to our users. IPAddressField also 
has some issues regarding the handling of blank strings vs None. This may 
result in unexpected behaviour or failures on some databases, but can't be 
fixed as it would break backwards compatibility. These are fixed in 
GenericIPAddressField.

To sum it up, the overhead may be an issue for users for which storage is very 
critical, and who will only need to store IPv4 addresses. Particularly the 
latter situation seems doubtful to me, as IPv6 adoption will only increase. 
However, even if these users exist, they can still create their own field. But 
users like this will be extremely rare, compared to those being hit by issues 
or confusion caused by the continued existence of IPAddressField.

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecating ipaddressfield

[Erik Romijn]

Hi Michael,

On Aug 25, 2013, at 12:07 AM, Michael Manfre  wrote:

> IPAddressField is meant for IPv4 addresses and GenericIPAddressField is for 
> both IPv4 and IPv6. Most backends define different database data types for 
> each of those fields. E.g. mysql is char(15) vs char(39). Forcing the larger 
> data type on users doesn't make sense. 
> 
> IPAddressField and GenericIPAddressField are similar to the various integer 
> fields. When BigIntegerField was added to the core, IntegerField and 
> SmallIntegerField still had their purpose.

I understand your comparison, but the situation is a little different here. The 
integer fields you refer to actually have different storage size requirements 
in many database backends. But for GenericIPAddressField in PostgreSQL and 
SQLite, the column types are the same - INET and TEXT.

On MySQL, the type is not char(15) vs char(39), but varchar(15) vs varchar(39). 
The storage size required for a varchar is the same for any length from 1 to 
255: one byte to store the content length, and then the bytes of the content. 
So storage size or performance is not affected. On Oracle, it's VARCHAR2(15) vs 
VARCHAR2(39) - I assume they store it similar to MySQL.

In other words, if you replace an IPAddressField with a GenericIPAddressField 
and store the same data, storage size or database performance is not affected, 
even though the column type may need to be changed.

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecating ipaddressfield

[Erik Romijn]

Hello all,

On May 18, 2013, at 2:07 PM, Erik Romijn  wrote:
> As far as I know, IPAddressField has no current features that are not also 
> available in a GenericIPAddressField. Therefore, I suggest that we, some time 
> from now, deprecate IPAddressField, in favour of GenericIPAddressField.

Since this initial mail last May, I haven't seen any opinions against 
deprecating IPAddressField, on this list or in #20439 [1].

I therefore propose that we start the deprecation of IPAddressField in 1.7, in 
favour of GenericIPAddressField (which was introduced in 1.4). That means 
PendingDeprecationWarning in 1.7, DeprecationWarning in 1.8 and removal in 1.9. 
Obviously, I'll document how users can migrate - even if they don't use South 
it's quite simple.

What do you think?

[1] https://code.djangoproject.com/ticket/20439

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

maintaining of new localflavor packages

[Erik Romijn]

Hello all,

With the separation of django-localflavor-* from Django core, one of the 
discussed advantages is that each localflavor package can have its own 
maintainer(s). Have we established a process for signing up for this? I 
couldn't find anything in docs or discussions.

The reason I ask, is that I'd like to volunteer for maintaining 
django-localflavor-nl.
As far as I could see there are currently no maintainers other than the Django 
core developers. Some immediate work I'd like to do is to make sure it gets on 
PyPI, and there's been a pull request open for months (which needs some local 
knowledge).

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

deprecating ipaddressfield (at some time)

[Erik Romijn]

Hello all,

Since Django 1.4, we've added GenericIPAddressField, next to IPAddressField. 
The new GenericIPAddressField supports IPv4 as well as IPv6 addresses, and does 
normalisation of IPv6 addresses. It can also be configured to only accept IPv4 
or IPv6 addresses.

As far as I know, IPAddressField has no current features that are not also 
available in a GenericIPAddressField. Therefore, I suggest that we, some time 
from now, deprecate IPAddressField, in favour of GenericIPAddressField.

For users, it is database-dependent whether IPAddressFields can just be 
replaced with GenericIPAddressFields: on PostgreSQL and SQLite, no changes are 
needed; schema changes are needed on MySQL and Oracle. Examples are listed in 
the 1.6 release notes[1], as we just made the same change for comments.

Is there anyone who sees any issues with this? I'm also not sure what timeline 
would be appropriate.

I have created ticket #20439[2] to keep track of this issue.

cheers,
Erik

[1] 
https://docs.djangoproject.com/en/dev/releases/1.6/#storage-of-ip-addresses-in-the-comments-app
[2] https://code.djangoproject.com/ticket/20439

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Good practices for production settings

[Erik Romijn]

Hi Aymeric,

On Mar 17, 2013, at 6:33 PM, Aymeric Augustin 
 wrote:
> Daniel Quinn worked on a list of good practices for production settings at the
> Utrecht sprint. I completed the patch and I'd like to commit the result:

I like the patch overall. I have two comments:

For HTTPS, I think it would be good to stress even more that HTTPS needs not 
only to be set up, but that it's also essential to redirect all HTTP requests 
to HTTPS. Some may see this as implied when you set up HTTPS, but it may not be 
obvious to everyone, and the problems you'd run into with secure cookies can be 
incredibly nasty to debug.

For databases, I think we should also specifically recommend never to have 
passwords in source control. Same as SECRET_KEY, really.

cheers,
Erik



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Erik Romijn]

Hi all,

It seems to me we are mixing a few different discussions here:
1. Should Django core have as few database backends as possible?
 1a. If yes, which ones should stay in Django core?
2. What should we do, if anything, with the current situation where 
   it seems difficult to guarantee the quality of the Oracle backend?
3. Should a MSSQL Django backend be included in Django core?

Regarding question 1, I feel we should keep a fair set of backends,
like the current one, included in Django core.

Yes, we could move them to separate projects. All the same arguments 
apply here as why it's not necessarily good for a project to end up
in contrib. However, in theory any component of Django could be moved 
out of core and be independently maintained. The whole ORM, the 
templating system, the CSRF protection, and so on. I haven't seen any 
reason why we should move the MySQL backend out, but not the templating 
system.

Besides that, the close integration and development of all these parts 
is exactly the reason I like Django. When I download a version of Django,
or upgrade, I know that all components in there will work well together. 
I can run my site on any of the supported databases, and they will all 
work together with the provided admin. I can build forms on the models 
I build with the ORM. The forms will nicely fit in with the templates.

When I started using Django, I had looked at several alternatives which 
were more modular. However, they required me to make tons of choices, 
each involving numerous consequences. If I picked ORM A, I could have 
databases X, Y and Z, but no admin. For the admin I had to use ORM B, 
but that did not support database Z or many to many fields. And so on.
When I tried Django, it was a relief to see I could download a single 
package, and everything would just work together.

If we move database backends out of core, my big concern is that 
the same will happen there. This is fine for many components we use 
in many Django projects - but not for something as fundamental as the 
database backend. When the admin doesn't work on any of the officially
supported backends, that should be a release blocker for Django itself,
because I think it will be a blocker for the users.

Regarding question 2, Oracle support, I think a great step forward has
been made with the addition of Oracle to the Django continuous 
integration setup. That alone should help us improve the consistent 
quality of Oracle support.

cheers,
Erik 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ModelForms and the Rails input handling vulnerability

[Erik Romijn]

Hello Luke and others,

On Jun 13, 2012, at 1:16 AM, Luke Plant wrote:
> On django-core we've been discussing an issue that was security related.
> However, we decided it wasn't urgent enough to warrant a security
> release, and so we're moving the discussion here (especially because we
> couldn't agree on what to do).

Especially after seeing Jessica McKellar's keynote at Djangocon EU, on
the experience of novice developers when using Django, I strongly feel
we should not leave the situation as it is. Although this risk and it's 
mitigations may be obvious to people on this list, a more novice 
developer using Django is much more likely to overlook this issue.

Many have made valid points that option two, three, or any other, may be 
seen as difficult for the developer. And that may motivate developers to 
use any of the mentioned Python one-liners to revert functionality back 
to the existing situation. However, with any system we devise to make 
anything secure, there are lazy shortcuts to break that security. But if 
we do nothing, everyone will be exposed to this risk. If we tighten
security, and some projects will use methods to revert this security
improvement, all the others are still more secure than before. Obviously,
it's also our role to make sure we provide proper example code in the
documentation.

Basically, even if every existing Django project would, being lazy, use
these one-liners in their existing forms and therefore receive no
security benefit from this change, we would still be making an
improvement for all the new projects to be started.


Having said that, there's the question of option two or three. If most
forms we use in our Django apps already exclude one or more fields 
today, there is little to no extra effort in option 3 compared to 
option 2 - as those forms would require the same work when Meta.exclude 
is dropped. If the effort for both options is equal (for the developers),
then I figure option 3 would be best.

Looking at my own projects, all editing of data in ModelForms is tied
to authentication, with a FK to the user. Which means all my ModelForms
use Meta.exclude already. Therefore, there is no difference in effort
between option 2 or 3 for those apps. But my apps are just a small sample.


Summary: I feel we should tighten this. The fact that this will be worked 
around by some, is not a reason for me to simply do nothing. When 
considering option 2 vs 3, we should, probably, also consider the actual
impact: how often do we create ModelForms with neither Meta.fields nor
Meta.exclude today?

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: discrepancy in default CSRF settings

[Erik Romijn]

Hi,

On Apr 9, 2012, at 11:32 AM, mjl Martin J. Laubach wrote:
> In the corresponding view functions, ensure that the 
> 'django.core.context_processors.csrf' context processor is being used. 
> Usually, this can be done in one of two ways:
>   • Use RequestContext, which always uses 
> 'django.core.context_processors.csrf' (no matter what your 
> TEMPLATE_CONTEXT_PROCESSORS setting). [...]

Thanks for pointing that out you're absolutely right. Not sure how I managed to 
misread that every time :)

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

discrepancy in default CSRF settings

[Erik Romijn]

Hi,

In order to enable CSRF protection, one needs to add the CsrfViewMiddleware to 
the middleware classes, and add the CSRF context processor to the context 
processors.

However, it seems that the defaults are to add the middleware, but not the 
context processor. Is there a specific reason for this?

After all, if we would not want to enable CSRF protection by default, we should 
include neither the middleware nor the context processor. If we do want it to 
be default, both should be included. The current defaults seem to be halfway 
between these options.

Should we not just add the CSRF context processor to the default context 
processors? Or is there an underlying reason to keep it out?

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ipv6 support for runserver - stuck in DDN for 2 yrs

[Erik Romijn]

Hi,

Ramiro Morales wrote:
> On Fri, May 28, 2010 at 7:25 AM, Erik Romijn  wrote:
>>
>> I noticed that there is a patch for IPv6 support in runserver,
>> http://code.djangoproject.com/ticket/7735 , and a maintainer willing to
>> make it cleanly apply to the latest trunk.
> 
> Could you please expand on the 'a feature we should have' part?.

At a point in the not too far future, there will be IPv6-only hosts.
They will benefit from having runserver being able to listen on IPv6.

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

ipv6 support for runserver - stuck in DDN for 2 yrs

[Erik Romijn]

Hi,

I noticed that there is a patch for IPv6 support in runserver,
http://code.djangoproject.com/ticket/7735 , and a maintainer willing to
make it cleanly apply to the latest trunk.

However, for some reason it's been stuck in DDN for two years. Why is
this? It looks to me like a simple patch for a feature we should have.

Can this be moved along, or is there something blocking it?

cheers,
Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.