Re: resurrecting an old friend, whitespace in forms, #6362

[Tim Chase]

[slightly reordered]
On 2015-02-04 18:25, Collin Anderson wrote:
> Also, did we decide if the Model-field-layer or Form-field-layer
> would be better?

I think the Form-field layer is definitely the place for it.  If I do

  my_model.my_text_field = " leading and trailing "

I expect that value to make it in there, spaces and all.  But if it
comes from a form, the form-field should default to assuming that
leading/trailing whitespace is an accident.  There have been plenty
of times that I've copied/pasted data and missed that
leading/trailing whitespace was included.  E.g.: copying from Excel
is notoriously bad at including trailing newlines.

> I can't think of many cases where trailing whitespace has been an
> issue for TextFields. Has this been an issue for people? I could
> imagine some people would want a trailing newline on TextFields.

My password-generator/manager can include spaces in passwords which
occasionally come up at the beginning/end of the resulting password.
Since it auto-types the value for me, I don't usually give it a
thought. But it has stung me once or twice when a site has a password
field that eats the whitespace.  Thus stung, I tend to no longer
include spaces in my generated passwords these days.  But again, at
the form-level, a TextInput could strip while a PasswordInput could
retain, and the underlying models.CharField would preserve whatever
the form hands to it.

My $0.01 on the matter,

-tkc


-- 
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/20150204215544.25d97f11%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Paul McMillan]

I'll reply to several emails at once here:

> If we add Origin checking, could we then allow a missing referrer and token?

Yes, we can support the origin header and allow a missing referer.

There's a ticket for that here:
https://code.djangoproject.com/ticket/16010
and I agree that it's long overdue. Do we have any information on
whether the referrer meta tag also influences the origin header? If it
doesn't, this whole conversation is a bit pointless...

> Aren't there existing security mechanisms to handle these situations?
> It seems like this is sending the wrong message. Django should be
> pushing developers and admins for the best solution to security and
> privacy concerns.
>
> Prevent HTTP when using HTTPS: use HSTS. (Apparently not supported by IE11 
> [0])

HSTS fixes the problem after the first visit, it can't fix the problem
before the user has visited the site (or ever in IE11, or for sites
which need unencrypted subdomains, or which are served at a
subdomain). We need to provide the best protection we can, so we still
need to check the referer.

As Aymeric said, the XFO header doesn't do anything to prevent a MITM
from sending whatever they want.

> However, In my opinion, the user's privacy needs go beyond this one
> scenario.

I will remind you that suppressing the referer header in question does
_absolutely nothing_ to enhance your user's privacy since it is only
relevant when the user is making a post from one page of your site to
another page of your site. Your webserver logs each of those requests,
and so where the traffic came from is immediately obvious. I agree
that chrome should support no-referrer-when-crossorigin, but since all
of this conversation is in reference to a proposed standard which is
not finalized yet, I would argue that this is an issue you can and
should bring up with the editors of the referrer-policy draft spec
(last revised 6 days ago). If they update the spec, I expect that
chrome will be updated to match it in short order.

> Is there detailed documentation on the type of attack this REFERER
> check guards against? Whether Django documentation or external
> documentation is fine. I would like to have a firm understanding of
> the real problem and how this solves it.

We don't have detailed documentation about every type of CSRF attack
that we defend against (such a document would be impossible to
maintain). However, I will try to lay this out more clearly for you
here.

setup:
user -> mitm -> server

Server is configured properly:
* HTTPS with good ciphers
* long-lived HSTS including all subdomains, served from yoursite.com
* X-Frame-Options: Deny
* Secure cookies
* permanent redirect from http to https

The user has never  been to your site on this computer before (maybe
they're logging in from a library computer, or a friend's computer, or
this is their first visit to your site).

The user types yoursite.com into the address bar and hits enter.

The mitm sees the request for http://yoursite.com, and rewrites the
301 redirect response your server sends to add a csrftoken=aaa cookie.

The user continues to your website. They log in.

Some time later, the user browses to aol.com (or any other insecure
site). The mitm sees this traffic, and on-the-fly, rewrites the html
that aol.com serves to include a script which posts a form to your
server, including a form field containing the CSRF value that the
attacker now knows (because the attacker set the csrf cookie in the
first place). This post (because it is prepared by the user's browser)
includes all cookies set for your domain (including the session and
the csrf token).

The user's browser may or may not send a referer with this post, but
in either case the origin does NOT match your original server, and
Django rejects the attack. If we remove the referer check in Django,
this attack is accepted (since it has a correct matching CSRF token
and a valid user session), and your application is compromised.

For websites and browsers that don't support HSTS (or websites which
aren't at the top level domain, or which don't include all subdomains
in the HSTS), this attack works every single time the user visits your
page. For browsers which do support HSTS (and your server has it
enabled) the attack is viable any time until the first time a browser
visits your page. Django has to provide the _best_ possible CSRF
protection it can, so it is not an option to exclude protection for
the first visit, or for sites which use non-https subdomains or parent
domains, or for browsers that don't support HSTS.

Hopefully you see why this check is important. You should find out
whether the referrer metatag also influences the origin header - if it
doesn't, fixing the ticket mentioned above would make most of your
concerns go away.

Regards,
-Paul

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

Re: resurrecting an old friend, whitespace in forms, #6362

[Curtis Maloney]

I'm certainly leaning on the side of "strip by default" because, like many
others, I feel it's the expected default -- users just don't get it -- and
have been bitten by it before.

I think I'll have a PR for this later tonight...

--
Curtis


On 5 February 2015 at 14:23, charettes  wrote:

> Like Russ I think this should be at the form level.
>
> Since both db.CharField and db.TextField use a form.CharField the
> stripping implementation should be done there.
>
> I commented here because I recently fixed a related bug in an application
> I maintain where a trailing white-space was not striped from an URLField
> form input. Since browsers automatically strip trailing white-space in urls
> (e.g. href=" example.com/path " == href="example.com/path") the anchor in
> the widget we provide was pointing to the correct resource when clicked by
> the user. However, when our system appended a querystring (By using the
> urllib and urlparse modules) for analytics purposes (e.g "example.com/path
> ?param=value") the white-space ended up making the whole URL invalid since
> the "/path " lead to a 404.
>
> Simon
>
> Le mercredi 4 février 2015 21:25:02 UTC-5, Collin Anderson a écrit :
>
>> Hi All,
>>
>> I'd be ok with a well thought-out strip-by-default.
>>
>> - I think most of my problems have been with trailing whitespace on
>> CharFields.
>> - I once have seen a minor unintentional leading whitespace. I think I
>> also may have once used a leading whitespace for sorting purposes, but I'd
>> be ok with even having leading whitespace stripped by default.
>>
>> I can't think of many cases where trailing whitespace has been an issue
>> for TextFields. Has this been an issue for people? I could imagine some
>> people would want a trailing newline on TextFields. However, peeking at
>> what other frameworks do, I'd be ok with this by default too :)
>>
>> Also, did we decide if the Model-field-layer or Form-field-layer would be
>> better?
>>
>> Collin
>>
>> On Wednesday, February 4, 2015 at 5:51:30 PM UTC-5, Shai Berger wrote:
>>>
>>> On Wednesday 04 February 2015 11:00:50 Tom Christie wrote:
>>> > > it will be backwards incompatible for every Django installation out
>>> >
>>> > there, but also because throwing away data that the user actually
>>> entered
>>> > should be an opt-in, not opt-out behavior.
>>> >
>>> > If adequately called out I think there'd be a valid case that the
>>> current
>>> > and future issues it'll be causing to applications right now would
>>> outweigh
>>> > the risk of compatibility breakages. I can see a couple of cases where
>>> I
>>> > might not want stripped whitespace, but only in slightly contrived and
>>> edge
>>> > case situations.
>>> >
>>> > Validating and normalizing input at the field level in a way that
>>> supports
>>> > the common case by default seems like a good plan to me. I'm not sure
>>> I see
>>> > any great difference between a user entering "3.1" in an integer field
>>> and
>>> > having 3 returned is so very different from having "hello " return
>>> "hello"
>>> > on a char field. And we're not of course throwing anything away at the
>>> > `request.POST` or `Form` layer - it's only once we're validating an
>>> > individual field that the normalization is being applied.
>>> >
>>> > I don't have an great investment in this either way around, but I
>>> think
>>> > it's a valid user-focused improvement worth considering *if* someone
>>> > actually puts together a pull request for it.
>>>
>>> I agree with this as well; I'd argue, though, that there is a difference
>>> between leading and trailing whitespace. Leading whitespace is usually
>>> visible
>>> and, to my mind, much more likely to be intentional.
>>>
>>> Shai.
>>>
>>  --
> 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/ff91cec7-90a2-4db3-8747-97d333ad218b%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/ms

Re: resurrecting an old friend, whitespace in forms, #6362

[charettes]

Like Russ I think this should be at the form level.

Since both db.CharField and db.TextField use a form.CharField the stripping 
implementation should be done there.

I commented here because I recently fixed a related bug in an application I 
maintain where a trailing white-space was not striped from an URLField form 
input. Since browsers automatically strip trailing white-space in urls 
(e.g. href=" example.com/path " == href="example.com/path") the anchor in 
the widget we provide was pointing to the correct resource when clicked by 
the user. However, when our system appended a querystring (By using the 
urllib and urlparse modules) for analytics purposes (e.g "example.com/path 
?param=value") the white-space ended up making the whole URL invalid since 
the "/path " lead to a 404.

Simon

Le mercredi 4 février 2015 21:25:02 UTC-5, Collin Anderson a écrit :
>
> Hi All,
>
> I'd be ok with a well thought-out strip-by-default.
>
> - I think most of my problems have been with trailing whitespace on 
> CharFields.
> - I once have seen a minor unintentional leading whitespace. I think I 
> also may have once used a leading whitespace for sorting purposes, but I'd 
> be ok with even having leading whitespace stripped by default.
>
> I can't think of many cases where trailing whitespace has been an issue 
> for TextFields. Has this been an issue for people? I could imagine some 
> people would want a trailing newline on TextFields. However, peeking at 
> what other frameworks do, I'd be ok with this by default too :)
>
> Also, did we decide if the Model-field-layer or Form-field-layer would be 
> better?
>
> Collin
>
> On Wednesday, February 4, 2015 at 5:51:30 PM UTC-5, Shai Berger wrote:
>>
>> On Wednesday 04 February 2015 11:00:50 Tom Christie wrote: 
>> > > it will be backwards incompatible for every Django installation out 
>> > 
>> > there, but also because throwing away data that the user actually 
>> entered 
>> > should be an opt-in, not opt-out behavior. 
>> > 
>> > If adequately called out I think there'd be a valid case that the 
>> current 
>> > and future issues it'll be causing to applications right now would 
>> outweigh 
>> > the risk of compatibility breakages. I can see a couple of cases where 
>> I 
>> > might not want stripped whitespace, but only in slightly contrived and 
>> edge 
>> > case situations. 
>> > 
>> > Validating and normalizing input at the field level in a way that 
>> supports 
>> > the common case by default seems like a good plan to me. I'm not sure I 
>> see 
>> > any great difference between a user entering "3.1" in an integer field 
>> and 
>> > having 3 returned is so very different from having "hello " return 
>> "hello" 
>> > on a char field. And we're not of course throwing anything away at the 
>> > `request.POST` or `Form` layer - it's only once we're validating an 
>> > individual field that the normalization is being applied. 
>> > 
>> > I don't have an great investment in this either way around, but I think 
>> > it's a valid user-focused improvement worth considering *if* someone 
>> > actually puts together a pull request for it. 
>>
>> I agree with this as well; I'd argue, though, that there is a difference 
>> between leading and trailing whitespace. Leading whitespace is usually 
>> visible 
>> and, to my mind, much more likely to be intentional. 
>>
>> Shai. 
>>
>

-- 
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/ff91cec7-90a2-4db3-8747-97d333ad218b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Collin Anderson]

Hi All,

I'd be ok with a well thought-out strip-by-default.

- I think most of my problems have been with trailing whitespace on 
CharFields.
- I once have seen a minor unintentional leading whitespace. I think I also 
may have once used a leading whitespace for sorting purposes, but I'd be ok 
with even having leading whitespace stripped by default.

I can't think of many cases where trailing whitespace has been an issue for 
TextFields. Has this been an issue for people? I could imagine some people 
would want a trailing newline on TextFields. However, peeking at what other 
frameworks do, I'd be ok with this by default too :)

Also, did we decide if the Model-field-layer or Form-field-layer would be 
better?

Collin

On Wednesday, February 4, 2015 at 5:51:30 PM UTC-5, Shai Berger wrote:
>
> On Wednesday 04 February 2015 11:00:50 Tom Christie wrote: 
> > > it will be backwards incompatible for every Django installation out 
> > 
> > there, but also because throwing away data that the user actually 
> entered 
> > should be an opt-in, not opt-out behavior. 
> > 
> > If adequately called out I think there'd be a valid case that the 
> current 
> > and future issues it'll be causing to applications right now would 
> outweigh 
> > the risk of compatibility breakages. I can see a couple of cases where I 
> > might not want stripped whitespace, but only in slightly contrived and 
> edge 
> > case situations. 
> > 
> > Validating and normalizing input at the field level in a way that 
> supports 
> > the common case by default seems like a good plan to me. I'm not sure I 
> see 
> > any great difference between a user entering "3.1" in an integer field 
> and 
> > having 3 returned is so very different from having "hello " return 
> "hello" 
> > on a char field. And we're not of course throwing anything away at the 
> > `request.POST` or `Form` layer - it's only once we're validating an 
> > individual field that the normalization is being applied. 
> > 
> > I don't have an great investment in this either way around, but I think 
> > it's a valid user-focused improvement worth considering *if* someone 
> > actually puts together a pull request for it. 
>
> I agree with this as well; I'd argue, though, that there is a difference 
> between leading and trailing whitespace. Leading whitespace is usually 
> visible 
> and, to my mind, much more likely to be intentional. 
>
> Shai. 
>

-- 
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/22947f02-0b7c-4798-acc1-6be436a0da4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Usage of field cardinality flags in database schema backends

[Tim Graham]

Seems to me it would be useful to work with some external projects (like 
taggit) to convert their projects to use only public APIs -- otherwise we 
are stumbling around in the dark trying to figure out theoretical use cases.

On Monday, February 2, 2015 at 5:41:06 AM UTC-5, Anssi Kääriäinen wrote:
>
> I don't like the idea of extended usage of field.get_internal_type(). The 
> problem is that we haven't defined what the internal_type means, and it is 
> actually used for different meanings in different places of code currently.
>
> As an example, AutoFields have internal type as AutoField. The AutoField 
> value is needed so that we can create correct auto-increment SQL for the 
> schema. On the other hand, AutoField's internal type should also be an 
> IntegerField (because other than the autoincrement part, AutoField is just 
> like an IntegerField), and for example expressions do value casts 
> automatically for all fields whose internal_type ends with IntegerField. 
> So, now AutoField which should work exactly like an integer field for 
> expressions doesn't work like an integer field for expressions.
>
> Similar problems arise also when trying to define get_internal_type() for 
> relational fields. For example, on one hand ForeignKey's 
> get_internal_type() should be the same as the related field's type (because 
> the concrete field is of that type in the database), but on the other hand 
> it should be 'ForeignKey', so that we know it is a relation.
>
> We should define an exact meaning for get_internal_type(), and use the 
> method for only that. I haven't seen any explanation of the actual problems 
> usage of field flags in django.db causes. We have perfectly good flags to 
> use for checking if a field is a relational or a m2m relation, and we 
> should use those when needed.
>
>  - Anssi
>
> On Monday, February 2, 2015 at 10:49:11 AM UTC+2, Loïc Bistuer wrote:
>>
>> Thanks Markus for the detailed report. 
>>
>> On a conceptual level I think we should aim for: 
>>
>> - django.db.* only relies on get_internal_type(). 
>> - django.* only relies on field flags. 
>>
>> To address the immediate regressions I suggest we backport 
>> https://github.com/django/django/pull/4002/files as far back as 1.7. 
>> That would address #24236 without requiring 
>> https://github.com/django/django/pull/3998/files. 
>>
>> In master: 
>>
>> - Replace all isinstance(field.rel) by isinstance(field) as a first step, 
>> this will help normalize things for future refactors (i.e. composite / 
>> virtual fields refactor, refactor of *Rel into proper fields like 
>> ReverseForeignKey, etc.) 
>>
>> - Replace all isistance(field) by get_iternal_type() in the ORM. 
>>
>> - More tricky, replace all isinstance(field) in the rest of django by 
>> cardinality flag when possible and identify every place where we can't do 
>> it yet because we rely on the implementation of these fields. 
>>
>> -- 
>> Loïc 
>>
>> > On Jan 31, 2015, at 18:19, Markus Holtermann  
>> wrote: 
>> > 
>> > Hey all, 
>> > 
>> > Since Django 1.8 (currently in alpha state), model fields gained 
>> cardinality flags as part of the _meta refactoring. So, there is 
>> one_to_one, one_to_many, many_to_one and many_to_many. These flags are 
>> currently only used inside user-facing APIs such as forms and the admin. 
>> > 
>> > Furthermore model fields have a get_internal_type() method that returns 
>> self.__class__.__name__ if they don't explicitly override that function (as 
>> many of the built-in fields do). This method is heavily used inside the 
>> backends. 
>> > 
>> > Besides those two ways to "try" to figure out what Django has to do in 
>> a certain situation, the code uses e.g. isinstance(field.rel, 
>> ManyToManyRel) and isinstance(field, ManyToManyField) to check for 
>> many-to-many relationships. 
>> > 
>> > This is quite confusing. At least to me. In 
>> https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8
>>  
>> I committed a patch that uses field.many_to_many in order to figure out if 
>> a certain column needs to be copied from one table to another (it doesn't 
>> if it's an m2m relation) when altering a table on SQLite. 
>> > 
>> > However changing that to use get_internal_name() and keep existing code 
>> working is not trivial since neither ForeignKey nor ManyToManyField or 
>> OneToOneField have those methods defined. Thus fields inheriting from 
>> either of them need to explicitly define the method to return "ForeignKey", 
>> "ManyToManyField" or "OneToOneField". (The backport of that patch to 1.7 
>> unfortunately breaks existing projects). 
>> > 
>> > I have a pull request open to fix the issue on 1.7 related to m2m 
>> fields: https://github.com/django/django/pull/3998 . 
>> > 
>> > However, I don't really like that repetitive pattern of checking for 
>> inheritance and get_internal_type(). I'm thinking about keeping the pattern 
>> in 1.8 (and replacing the above checks with the one in the pull request) 

Re: resurrecting an old friend, whitespace in forms, #6362

[Shai Berger]

On Wednesday 04 February 2015 11:00:50 Tom Christie wrote:
> > it will be backwards incompatible for every Django installation out
> 
> there, but also because throwing away data that the user actually entered
> should be an opt-in, not opt-out behavior.
> 
> If adequately called out I think there'd be a valid case that the current
> and future issues it'll be causing to applications right now would outweigh
> the risk of compatibility breakages. I can see a couple of cases where I
> might not want stripped whitespace, but only in slightly contrived and edge
> case situations.
> 
> Validating and normalizing input at the field level in a way that supports
> the common case by default seems like a good plan to me. I'm not sure I see
> any great difference between a user entering "3.1" in an integer field and
> having 3 returned is so very different from having "hello " return "hello"
> on a char field. And we're not of course throwing anything away at the
> `request.POST` or `Form` layer - it's only once we're validating an
> individual field that the normalization is being applied.
> 
> I don't have an great investment in this either way around, but I think
> it's a valid user-focused improvement worth considering *if* someone
> actually puts together a pull request for it.

I agree with this as well; I'd argue, though, that there is a difference 
between leading and trailing whitespace. Leading whitespace is usually visible 
and, to my mind, much more likely to be intentional.

Shai.

Re: resurrecting an old friend, whitespace in forms, #6362

[Carl Meyer]

On 02/04/2015 02:00 AM, Tom Christie wrote:
>> it will be backwards incompatible for every Django installation out
> there, but also because throwing away data that the user actually
> entered should be an opt-in, not opt-out behavior.
> 
> If adequately called out I think there'd be a valid case that the
> current and future issues it'll be causing to applications right now
> would outweigh the risk of compatibility breakages. I can see a couple
> of cases where I might not want stripped whitespace, but only in
> slightly contrived and edge case situations.
> 
> Validating and normalizing input at the field level in a way that
> supports the common case by default seems like a good plan to me. I'm
> not sure I see any great difference between a user entering "3.1" in an
> integer field and having 3 returned is so very different from having
> "hello " return "hello" on a char field. And we're not of course
> throwing anything away at the `request.POST` or `Form` layer - it's only
> once we're validating an individual field that the normalization is
> being applied.
> 
> I don't have an great investment in this either way around, but I think
> it's a valid user-focused improvement worth considering *if* someone
> actually puts together a pull request for it.

I agree with all of what Tom says.

Carl

-- 
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/54D24C59.5010801%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Jon Dufresne]

On Wed, Feb 4, 2015 at 5:59 AM, Erik Romijn  wrote:
>
> 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?

I am not instructing my users to do anything with their headers. This
would never be feasible for me. I mentioned some users may do so
independently.

I *want* to help control referrers using the new meta referrer tag.
This is a new feature not yet supported in all major browsers. See:

https://blog.mozilla.org/security/2015/01/21/meta-referrer/
https://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-meta
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta (search
referrer on page)

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

Thanks. Aymeric suggested a similar scheme to me earlier. I will take
it under consideration.

However, In my opinion, the user's privacy needs go beyond this one
scenario. When going cross origin, it is never the business of the
final destination where I started. Interestingly enough, the links
above have an "origin-when-crossorigin" mode (but not
"no-referrer-when-crossorigin"). However, this is not supported on
Chrome and so it defaults to "no-referrer" which, once again, breaks
Django POST over HTTPS.

-- 
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/CADhq2b7MYsFmnXdbOREzmv-5HtnzEdEr0ci8%2B7EfbGx%3DABSjPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Jon Dufresne]

On Tue, Feb 3, 2015 at 11:45 PM, Aymeric Augustin
 wrote:
> Le 4 févr. 2015 à 03:31, Jon Dufresne  a écrit :
>>
>> Prevent the application from being served in an attacker's iframe: use
>> X-Frame-Options. (Supported by all major browsers [1])
>
> That's irrelevant in the scenario we're discussing here. The iframe Paul 
> talks about would be injected by a MITM. It's under the attacker's control, 
> not your control.

Thank you for the calcification.

Is there detailed documentation on the type of attack this REFERER
check guards against? Whether Django documentation or external
documentation is fine. I would like to have a firm understanding of
the real problem and how this solves it.

Cheers,
Jon

-- 
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/CADhq2b7EuwAuyJAvge00qNjgttFTjtJ0q9TPy4S1hBZ1XfsdmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating contributing documentation

[Riccardo Magliocchetti]

Hi Tim,

Il 04/02/2015 13:24, Tim Graham ha scritto:

Hi Riccardo,

Thanks for the feedback. Maybe adding a link to the patch review
checklist [1] to the contributing tutorial would be sufficient. Most of
the points you've covered are valid and are covered in the rest of the
contributing docs. I'd like not to duplicate information if possible,
but please do submit a pull request with changes you feel are appropriate.



[1]
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist


Ah! here's the docs i need :)

Anyway here's a pull request that add a couple of cross references to 
possible other interesting pages to the reader:


- from first patch tutorial to submitting patches, in case someone 
looking for a patch checklist get here from a search engine
- adding a link to the aforementioned tutorial from the new contributors 
page for newbies looking for the basics.


https://github.com/django/django/pull/4050

hth,
riccardo

--
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/54D232C1.5090704%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Tim Graham]

Reminder that the 1.8 beta release is scheduled for twelve days from now: 
Monday, February 16. 

Please check this filter for remaining blockers for beta:

https://code.djangoproject.com/query?status=assigned&status=new&version=1.8alpha1&severity=Release+blocker&or&status=assigned&status=new&keywords=~1.8-beta&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime

I'll follow up next week to ensure we have owners for any issues that 
remain after the weekend.

On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>
> I think master is stabilizing and the number of unsolved regressions 
> should be ~0 by tomorrow. I'd like to release the alpha around 2100 UTC 
> tomorrow +/- ~4 hours depending on how things go with the remaining issues. 
> Let me know if there is anything you think needs to be in the alpha that 
> wouldn't meet this deadline.
>
> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn wrote:
>>
>> Congratulations! Looks like you've steadily moved it through.
>>
>> Tino
>>
>> On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  wrote:
>>
>>> We did it -- all features are in or out for alpha. Please consider 
>>> master frozen for new features until we cut the stable/1.8.x branch later 
>>> this week. Feel free to commit code cleanups and/or bug fixes until then.
>>>
>>>
>>> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:

 Here is the fifth update with several days to go until alpha. I believe 
 we are on track for a feature freeze at the end of day on Monday. Let's 
 see 
 how things go, but I'd like to cut the stable/1.8.x branch and issue the 
 alpha release by the following Friday (a week from today).

 New blockers:

 #24075  - Can't migrate 
 contenttypes and auth to zero 
 
 Owner: Simon
 Status: This is an existing issue on 1.7, but addressing it seems to 
 require (or at least, would be a lot easier) with the proposed new feature 
 of adding a "plan" argument to the post_migrate() signal. There is a patch 
 in the works.

 Resolved since last time:

 #23861 - 
  Fields referenced in 
 migrations cannot be (re)moved, even if migrations have been squashed 
 
 Owner: Tim
 Now: I polished and committed the patch for this.
 Last time: I committed a patch for the second ticket and will polish 
 the patch for the first issue.

 Most of the issues tagged "1.8-alpha" have been completed or deferred. 
 The two main ones that remain are "Case/When expressions" and "Allowing 
 expressions to be used in order_by queryset method." Depending on what 
 progress is made over the weekend on these issues, they may or may not 
 make 
 it into 1.8.
 https://code.djangoproject.com/query?status=assigned&;
 status=new&keywords=~1.8-alpha

 On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>
> Thank you, Tim, for shepherding this.
> On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:
>
>> Here is the fourth update with a week to go until alpha. At this 
>> time, I am thinking we'll have the feature freeze on Monday, January 12 
>> as 
>> planned, but perhaps issue the actual alpha release a couple days later 
>> just to give some time for some extra polish in case any large patches 
>> are 
>> committed next weekend.
>>
>> #23861 - 
>>  Fields referenced in 
>> migrations cannot be (re)moved, even if migrations have been squashed 
>> 
>> #23891  - Revise 
>> deprecation / removal timeline for IPAddressField 
>>  (resolved)
>> Owner: Tim
>> Now: I committed a patch for the second ticket and will polish the 
>> patch for the first issue.
>> Last time: I've implemented the system check solution I proposed and 
>> am waiting for review and/or concerns with this approach.
>>
>> After completing the issue above, I'll prioritize any issues here:
>> https://code.djangoproject.com/query?status=assigned&;
>> status=new&keywords=~1.8-alpha
>>
>> Resolved since last time:
>>
>> #22340 -  
>>  Legacy Table Creation 
>> Methods Not Properly Deprecated 
>> 
>> Owner: Tim
>> Now: Resolved this by removing the deprecation as discussed in the 
>> ticket.
>> Last time: I took a closer look at this and don't think we need to do 
>> this deprecation at all as it doesn't seem to offer any 

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: Middleware+Transactions:

[Anssi Kääriäinen]

I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called for given middleware, and
this makes it impossible to implement a transaction middleware purely
as a middleware.

An idea... Would investigating and implementing better middlewares (or
urlpattern wrappers) make for a good GSoC project? Maybe the "wrap
URLs" approach could be part of the URL resolve refactoring GSoC
project?

 - Anssi

On Wed, Feb 4, 2015 at 1:52 PM, Florian Apolloner  wrote:
>
>
> On Wednesday, February 4, 2015 at 10:53:28 AM UTC+1, guettli wrote:
>>
>> Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be
>> accepted?
>
>
> Most likely not since one of the reasons why @atomic isn't applied via a
> middleware (which would then include the middlewares after it) is that the
> way middlewares currently work don't allow the usage of atomic. That said if
> you have a working patch we'd certainly look at it.
>
> Cheers,
> Florian
>
> --
> 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/49f603d3-af82-48e7-845d-50f4b8e7a530%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/CALMtK1HQuPx65-txHRUD92SqezN7HO%3D0a2QgdSquzVRyOKuJwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating contributing documentation

[Tim Graham]

Hi Riccardo,

Thanks for the feedback. Maybe adding a link to the patch review checklist 
[1] to the contributing tutorial would be sufficient. Most of the points 
you've covered are valid and are covered in the rest of the contributing 
docs. I'd like not to duplicate information if possible, but please do 
submit a pull request with changes you feel are appropriate.

[1] 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

- from my own experience it looks like that a pull request is required 
for review. Documentation say patches in the bugtracker are fine but 
have been asked to open pull request even with patches sitting in the 
ticket.

Yes, pull requests are preferred, especially for any non-trivial code 
changes. I still use attachments for smaller doc patches. We should likely 
recommend attachments only to those who cannot submit a pull request.

- there's no mention on the ready "Patch needs improvement" bit, again from 
my own 
experience there has been patches in the bugtracker for years because 
without that bit sets the patch is off the radar of reviewers 

I've thought to address this issue by improving the UI in Trac so that it 
translates the current flags to a sentence that summarizes the "next steps" 
for the ticket.
https://github.com/django/code.djangoproject.com/issues/33

- suggest to run pyflake8 on the file you changed, saves a review round 
trip 

This is covered in the patch review checklist.

- there should be some switch that makes deprecations warning fail on 
djangoci but i don't see them when running tests on my machine. That 
could easily done on developers machines to save a round trip while 
reviewing. Any hint please? 

This is covered in the "Deprecating a Feature" guide, which is linked from 
the patch review checklist.
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature

On Wednesday, February 4, 2015 at 4:31:31 AM UTC-5, riccardo.magliocchetti 
wrote:
>
> Il 04/02/2015 10:15, Riccardo Magliocchetti ha scritto: 
> > Hello, 
> > 
> > I'd like to update the contributing (docs/intro/contributing.txt) docs 
> > to make the process a bit smoother, here's some issues i've found: 
> > 
> > - from my own experience it looks like that a pull request is required 
> > for review. Documentation say patches in the bugtracker are fine but 
> > have been asked to open pull request even with patches sitting in the 
> > ticket. 
> > 
> > - there's no mention on the ready for checkin bit, again from my own 
> > experience there has been patches in the bugtracker for years because 
> > without that bit sets the patch is off the radar of reviewers 
>
> Here i meant the "patch needs improvement" bit 
>
> > - suggest to run pyflake8 on the file you changed, saves a review round 
> > trip 
> > 
> > - there should be some switch that makes deprecations warning fail on 
> > djangoci but i don't see them when running tests on my machine. That 
> > could easily done on developers machines to save a round trip while 
> > reviewing. Any hint please? 
> > 
> > If there's agreement with this i can open a pull request. 
> > 
> > Thanks, 
> > riccardo 
>
>

-- 
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/f84c8724-022b-431d-9c2d-c4b0dcb501dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Tom Christie]

> leaving a ticket open is a better signal for inviting discussion and 
patches.

There's been over 22,000 issues raised in Django's history. It's 
understandable and desirable that maintainers close off tickets 
aggressively if they don't think they should be tackled.

I wouldn't get too hung up on the process there - a sound argument and a 
bit of proactive work is all that's needed to convince folks to take the 
time to reassess something like that issue. Personally I think there's a 
good case to be made for this one so from my point of view, so I'd say go 
ahead, make the proposal, or better still a pull request, make the argument 
and *then* see if it is possible to reach a consensus.

There's clearly absolutely no guarantee it'd be accepted (there's two core 
members in this thread making different judgement calls on it, so it's 
*far* from cut & dried) but you can be sure that folks are willing to put 
the time in to listen to anyone willing to put in a bit of legwork.

Cheers,

  Tom :)

-- 
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/14bdc9b2-3cd5-4ca8-945b-891884da7c5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Middleware+Transactions:

[Florian Apolloner]

On Wednesday, February 4, 2015 at 10:53:28 AM UTC+1, guettli wrote:
>
> Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be 
> accepted? 
>

Most likely not since one of the reasons why @atomic isn't applied via a 
middleware (which would then include the middlewares after it) is that the 
way middlewares currently work don't allow the usage of atomic. That said 
if you have a working patch we'd certainly look at it.

Cheers,
Florian

-- 
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/49f603d3-af82-48e7-845d-50f4b8e7a530%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[frantisek holop]

Russell Keith-Magee, 04 Feb 2015 08:26:
> Jacob specifically said a good patch for this feature would be considered
> when he wontfixed #6362.

for me, leaving a ticket open is a better signal for
inviting discussion and patches.  when i see a wontfix
closed ticket in other projects it usually means "end
of story, dont bother" and/or "this is not an issue
that needs fixing".  but that's just me :)

> because throwing away data that the user actually entered should be an
> opt-in, not opt-out behavior.

data: yes, leading/trailing whitespace: no.

this is the critical point where we disagree.  when it
comes to that whitespace, it should be opt-out.

the web also seems to disagree with you. try any of the
forms starting at google search, usernames in login
forms, contact forms, they all throw away
leading/trailing whitespace -- and it's one less
problem their helpdesks must deal with.

leading/trailing whitespace is a usability issue, and a
mistake people make who do not realise how "unforgiving"
computers are when presented with
'username ' != 'username'.  for them whitespace is "air".

but i think the point is made and clear.  of course
it's possible to deal with this in django, it's just
more hassle than it could be and right now i feel
punished. i think many django projects simply
ignore the issue and delegate the blame to the user.


i am thinking of raising a ticket about the admin's
loginform not stripping its username, esp when adding a
user is actually protected against whitespace.
would that make sense?  it is trivial to fix :)

-f
-- 
underneath all these clothes i am completely naked!

-- 
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/20150204104002.GA18576%40obiit.org.
For more options, visit https://groups.google.com/d/optout.

Re: Middleware+Transactions:

[Thomas Güttler]

Thank you very much for your fast reply.

Our team discussed the solutions we see. At the moment we see this upgrade:

 - We stay with the older django version, and don't use atomic for the next 
months.
 - We provide a patch for django to provide 
settings.MIDDLEWARES_INSIDE_TRANSACTION
 - I hope django will include our patches in a newer version.
 - If the new version of django is released we can upgrade our code.

Explanation:

settings.MIDDLEWARES_INSIDE_TRANSACTION=['mymodule.middlewares.HandleChangesOfTransaction',
 ...]

HandleChangesOfTransaction is a class which does some magic at the beginning 
and end of each transaction.

Can you understand what I wrote?

Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be accepted?

Regards,
  Thomas Güttler


Am 03.02.2015 um 11:00 schrieb Aymeric Augustin:

Hi Thomas,

Both ways had advantages and drawbacks. Eventually I chose to include only the 
view function in the transaction for the
following reasons.

1) Django never made any guarantees about which process_* methods of middleware 
would be called. Therefore every
middleware must implemented defensively anyway, that is, leave a consistent 
state regardless of what methods are or
aren't called.

2) The goal of ATOMIC_REQUESTS is to prevent inconsistent modifications of the 
database in views. Since middleware run
for every view, they shouldn't introduce inconsistencies no matter what happens.

3) Most middleware don't touch the database. Database queries that run at every 
request aren't good for overall performance.

4) For lack of a better reason, keeping the database transactions short is more 
efficient.

1) and 2) really boil down to the fragility of how Django executes middleware. 
Not including middleware in transactions
reduces the risk that developers will make incorrect assumptions. 3) and 4) 
don't apply to your use case.

I looked at how reversion is implemented but I don't understand it sufficiently 
well to give advice.

This isn't a satisfying answer but I hope it helps.


--
Thomas Güttler
http://thomas-guettler.de/

--
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/54D1EC0C.9070604%40tbz-pariv.de.
For more options, visit https://groups.google.com/d/optout.

Re: Updating contributing documentation

[Riccardo Magliocchetti]

Il 04/02/2015 10:15, Riccardo Magliocchetti ha scritto:

Hello,

I'd like to update the contributing (docs/intro/contributing.txt) docs
to make the process a bit smoother, here's some issues i've found:

- from my own experience it looks like that a pull request is required
for review. Documentation say patches in the bugtracker are fine but
have been asked to open pull request even with patches sitting in the
ticket.

- there's no mention on the ready for checkin bit, again from my own
experience there has been patches in the bugtracker for years because
without that bit sets the patch is off the radar of reviewers


Here i meant the "patch needs improvement" bit


- suggest to run pyflake8 on the file you changed, saves a review round
trip

- there should be some switch that makes deprecations warning fail on
djangoci but i don't see them when running tests on my machine. That
could easily done on developers machines to save a round trip while
reviewing. Any hint please?

If there's agreement with this i can open a pull request.

Thanks,
riccardo


--
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/54D1E6EA.4010401%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Updating contributing documentation

[Riccardo Magliocchetti]

Hello,

I'd like to update the contributing (docs/intro/contributing.txt) docs 
to make the process a bit smoother, here's some issues i've found:


- from my own experience it looks like that a pull request is required 
for review. Documentation say patches in the bugtracker are fine but 
have been asked to open pull request even with patches sitting in the 
ticket.


- there's no mention on the ready for checkin bit, again from my own 
experience there has been patches in the bugtracker for years because 
without that bit sets the patch is off the radar of reviewers


- suggest to run pyflake8 on the file you changed, saves a review round trip

- there should be some switch that makes deprecations warning fail on 
djangoci but i don't see them when running tests on my machine. That 
could easily done on developers machines to save a round trip while 
reviewing. Any hint please?


If there's agreement with this i can open a pull request.

Thanks,
riccardo

--
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/54D1E33A.6060105%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Tom Christie]

> it will be backwards incompatible for every Django installation out 
there, but also because throwing away data that the user actually entered 
should be an opt-in, not opt-out behavior.

If adequately called out I think there'd be a valid case that the current 
and future issues it'll be causing to applications right now would outweigh 
the risk of compatibility breakages. I can see a couple of cases where I 
might not want stripped whitespace, but only in slightly contrived and edge 
case situations.

Validating and normalizing input at the field level in a way that supports 
the common case by default seems like a good plan to me. I'm not sure I see 
any great difference between a user entering "3.1" in an integer field and 
having 3 returned is so very different from having "hello " return "hello" 
on a char field. And we're not of course throwing anything away at the 
`request.POST` or `Form` layer - it's only once we're validating an 
individual field that the normalization is being applied.

I don't have an great investment in this either way around, but I think 
it's a valid user-focused improvement worth considering *if* someone 
actually puts together a pull request for it.

-- 
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/f62ee326-11a8-447b-a19c-3028b6e7453f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.