Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Carl Meyer 

On Feb 20, 2013, at 6:25 PM, Ian Kelly  wrote:
> On Feb 20, 2013 4:41 PM, "Carl Meyer"  wrote:
> > On 02/20/2013 04:25 PM, Nick Phillips wrote:
> > >> There was extensive back-and-forth discussion of this in writing the
> > >> patch. The issue is that in almost all cases the correct value of the
> > >> setting in local development and under test are different from the
> > >> correct value in production. So how much value is there in knowing the
> > >> tests pass, and/or it works locally? That doesn't really increase the
> > >> chances that you have it configured correctly in production.
> > >
> > > It would at least ensure that you were aware of it and had attempted to
> > > set it...
> >
> > That's true.
> 
> If you have a test tier where DEBUG=False, then the first request from an 
> actual browser would also detect this, would it not?
> 
Yes.

Carl

-- 
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Ian Kelly 
On Feb 20, 2013 4:41 PM, "Carl Meyer"  wrote:
>
> On 02/20/2013 04:25 PM, Nick Phillips wrote:
> >> There was extensive back-and-forth discussion of this in writing the
> >> patch. The issue is that in almost all cases the correct value of the
> >> setting in local development and under test are different from the
> >> correct value in production. So how much value is there in knowing the
> >> tests pass, and/or it works locally? That doesn't really increase the
> >> chances that you have it configured correctly in production.
> >
> > It would at least ensure that you were aware of it and had attempted to
> > set it...
>
> That's true.

If you have a test tier where DEBUG=False, then the first request from an
actual browser would also detect this, would it not?

-- 
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Carl Meyer 
On 02/20/2013 04:25 PM, Nick Phillips wrote:
>> There was extensive back-and-forth discussion of this in writing the
>> patch. The issue is that in almost all cases the correct value of the
>> setting in local development and under test are different from the
>> correct value in production. So how much value is there in knowing the
>> tests pass, and/or it works locally? That doesn't really increase the
>> chances that you have it configured correctly in production.
> 
> It would at least ensure that you were aware of it and had attempted to
> set it...

That's true.

>>  In the end,
>> our estimation was that requiring it to be configured in local dev and
>> testing would introduce quite a lot of hassle (and potentially a major
>> roadblock for new users), with very little gain to offset that.
> 
> What would the implications of having "localhost" in there be?

We considered this too (like I say, this question got a lot of
discussion :-) ). For people who actually connect to "localhost" in
local dev, it would be more or less the same as the current behavior.
For others (who don't), they'd have to set it.

But in the end, this just splits the difference in a way that doesn't
help. For any given user, either it "just works" for local dev (and we
thus lose the awareness benefit you mentioned above), or we force you to
deal with it all the time (and make things more of a hassle). We weighed
the options and chose to make it consistently the former.

Carl

-- 
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Nick Phillips 
On Tue, 2013-02-19 at 15:46 -0700, Carl Meyer wrote:
> Hi Nick,
> 
> On 02/19/2013 03:32 PM, Nick Phillips wrote:
> > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> > do, it seems rather problematic. In particular, that host verification
> > is apparently turned off while DEBUG is True or while testing.
> > 
> > Surely this makes it impossible to test, and makes it likely that
> > misconfigurations will not be picked up until deployed to a production
> > environment.
> >
> > Given that most setups require some customisation of settings for
> > dev/staging/production/whatever environments anyway, why not leave the
> > verification on at all times and allow us to ensure we get the right
> > hosts in the right environments?
> 
> There was extensive back-and-forth discussion of this in writing the
> patch. The issue is that in almost all cases the correct value of the
> setting in local development and under test are different from the
> correct value in production. So how much value is there in knowing the
> tests pass, and/or it works locally? That doesn't really increase the
> chances that you have it configured correctly in production.

It would at least ensure that you were aware of it and had attempted to
set it...

>  In the end,
> our estimation was that requiring it to be configured in local dev and
> testing would introduce quite a lot of hassle (and potentially a major
> roadblock for new users), with very little gain to offset that.

What would the implications of having "localhost" in there be?

> Note that it isn't impossible to test, if you want to; the check is
> "disabled" under test by means of setting ALLOWED_HOSTS to ['*'] for the
> duration of the test run, so if you want tests to exercise validation
> you can just use the override_settings decorator to temporarily change
> it for a test method or test case.

Ah, thanks - I was at least missing that.


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
Faculty of Medicine, University of Otago

-- 
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Carl Meyer 


On 02/20/2013 01:58 AM, Reinout van Rees wrote:
> On 19-02-13 23:32, Nick Phillips wrote:
>> I don't recall looking at the ALLOWED_HOSTS setting before.
> 
> Should there be a note in the 1.4 docs that the default ['*'] value is a
> temporary default value? That from 1.5 onwards it will be an empty list?
> 
> https://docs.djangoproject.com/en/1.4/ref/settings/#allowed-hosts

Yes, that's a good idea for the 1.3 and 1.4 docs, thanks for the
suggestion. Done.

Carl

-- 
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Reinout van Rees 

On 19-02-13 23:32, Nick Phillips wrote:

I don't recall looking at the ALLOWED_HOSTS setting before.


Should there be a note in the 1.4 docs that the default ['*'] value is a 
temporary default value? That from 1.5 onwards it will be an empty list?


https://docs.djangoproject.com/en/1.4/ref/settings/#allowed-hosts


Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-19 Thread Carl Meyer 
Hi Nick,

On 02/19/2013 03:32 PM, Nick Phillips wrote:
> I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> do, it seems rather problematic. In particular, that host verification
> is apparently turned off while DEBUG is True or while testing.
> 
> Surely this makes it impossible to test, and makes it likely that
> misconfigurations will not be picked up until deployed to a production
> environment.
>
> Given that most setups require some customisation of settings for
> dev/staging/production/whatever environments anyway, why not leave the
> verification on at all times and allow us to ensure we get the right
> hosts in the right environments?

There was extensive back-and-forth discussion of this in writing the
patch. The issue is that in almost all cases the correct value of the
setting in local development and under test are different from the
correct value in production. So how much value is there in knowing the
tests pass, and/or it works locally? That doesn't really increase the
chances that you have it configured correctly in production. In the end,
our estimation was that requiring it to be configured in local dev and
testing would introduce quite a lot of hassle (and potentially a major
roadblock for new users), with very little gain to offset that.

Note that it isn't impossible to test, if you want to; the check is
"disabled" under test by means of setting ALLOWED_HOSTS to ['*'] for the
duration of the test run, so if you want tests to exercise validation
you can just use the override_settings decorator to temporarily change
it for a test method or test case.

Carl

-- 
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: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-19 Thread Nick Phillips 
On Tue, 2013-02-19 at 14:50 -0600, James Bennett wrote:
> We've issued several security releases today. Details are in the blog
post:
> 
> https://www.djangoproject.com/weblog/2013/feb/19/security/
> 
> We recommend everyone carefully read this one, as it has an
> end-user-visible change requiring action beyond simply upgrading your
> Django package.
> 

I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
do, it seems rather problematic. In particular, that host verification
is apparently turned off while DEBUG is True or while testing.

Surely this makes it impossible to test, and makes it likely that
misconfigurations will not be picked up until deployed to a production
environment.

Given that most setups require some customisation of settings for
dev/staging/production/whatever environments anyway, why not leave the
verification on at all times and allow us to ensure we get the right
hosts in the right environments?

What am I missing?


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

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

ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-19 Thread James Bennett 
We've issued several security releases today. Details are in the blog post:

https://www.djangoproject.com/weblog/2013/feb/19/security/

We recommend everyone carefully read this one, as it has an
end-user-visible change requiring action beyond simply upgrading your
Django package.

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