Re: CSRF REASON_NO_REFERER with meta referrer tags

[Aymeric Augustin]

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.

-- 
Aymeric

-- 
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/81413F28-57FE-4A89-833B-54D120AD467F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Josh Smeaton]

For the record, I'm not disagreeing with you. I don't know enough about the 
topic to understand whether or not the referer check actually provides 
another layer of security. I think the questions you're asking are good 
ones.

Josh

On Wednesday, 4 February 2015 15:11:34 UTC+11, Jon Dufresne wrote:
>
> On Tue, Feb 3, 2015 at 7:09 PM, Josh Smeaton  > wrote: 
> > Just quickly, HSTS[0] and X-Frame-Options[1] are supported and 
> recommended 
> > in the security documentation already. As you point out though, HSTS 
> isn't 
> > yet a full solution, and, frankly, it scares me a little. Personally, I 
> > redirect the / path to HTTPS from HTTP and drop all other HTTP 
> connections. 
>
> I think that enhances and is consistent with my existing question. 
>
> If there are better mechanisms to secure against these attacks *and* 
> they are already recommended by Django, what is the CSRF REFERER check 
> doing that isn't already solved by these mechanisms? 
>
> By using these other security mechanisms to secure against the attack, 
> developers can then use the meta referrer tag to help with users' 
> privacy. 
>
> 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/8eda6c7e-bcc4-4e88-ab54-bf3399f6b4b6%40googlegroups.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 7:09 PM, Josh Smeaton  wrote:
> Just quickly, HSTS[0] and X-Frame-Options[1] are supported and recommended
> in the security documentation already. As you point out though, HSTS isn't
> yet a full solution, and, frankly, it scares me a little. Personally, I
> redirect the / path to HTTPS from HTTP and drop all other HTTP connections.

I think that enhances and is consistent with my existing question.

If there are better mechanisms to secure against these attacks *and*
they are already recommended by Django, what is the CSRF REFERER check
doing that isn't already solved by these mechanisms?

By using these other security mechanisms to secure against the attack,
developers can then use the meta referrer tag to help with users'
privacy.

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/CADhq2b7D2m%2BD4TJ%2BVF8XaeDFQ%3Dtfn2wdE4BFXzWWkhpFALyiMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Josh Smeaton]

Just quickly, HSTS[0] and X-Frame-Options[1] are supported and recommended 
in the security documentation already. As you point out though, HSTS isn't 
yet a full solution, and, frankly, it scares me a little. Personally, I 
redirect the / path to HTTPS from HTTP and drop all other HTTP connections.

[0[https://docs.djangoproject.com/en/1.7/topics/security/#ssl-https
[1]https://docs.djangoproject.com/en/1.7/topics/security/#clickjacking-protection

On Wednesday, 4 February 2015 13:31:49 UTC+11, Jon Dufresne wrote:
>
> On Tue, Feb 3, 2015 at 2:12 PM, Paul McMillan  > wrote: 
> > The referer check is primarily there to help make users who choose not 
> > to use HSTS safer. 
> > 
> > Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP 
> > page emulating your domain in an iframe on a different unencrypted 
> > page, even if you only ever serve your own page from HTTPS), and then 
> > post (from wherever) to your secured page. By forcing the post to come 
> > from the same domain, we've made this attack significantly less 
> > convenient. 
> > 
> > I agree that it's really unfortunate that we don't have a better 
> > mechanism for this in the browsers, but this still seems to be the 
> > best tradeoff we have right now. 
>
> 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]) 
>
> Prevent the application from being served in an attacker's iframe: use 
> X-Frame-Options. (Supported by all major browsers [1]) 
>
> These seem like much better solutions to the scenario you present. 
> What does the REFERER check do that is not handled by the above? 
>
> At that point, the user's privacy concerns could be handled with the 
> meta referrer tag. 
>
> [0] 
> https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security#Browser_compatibility
>  
> [1] 
> https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options#Browser_compatibility
>  
>

-- 
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/37f6238d-b825-4042-92f9-c911509c5c1f%40googlegroups.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 2:12 PM, Paul McMillan  wrote:
> The referer check is primarily there to help make users who choose not
> to use HSTS safer.
>
> Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP
> page emulating your domain in an iframe on a different unencrypted
> page, even if you only ever serve your own page from HTTPS), and then
> post (from wherever) to your secured page. By forcing the post to come
> from the same domain, we've made this attack significantly less
> convenient.
>
> I agree that it's really unfortunate that we don't have a better
> mechanism for this in the browsers, but this still seems to be the
> best tradeoff we have right now.

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

Prevent the application from being served in an attacker's iframe: use
X-Frame-Options. (Supported by all major browsers [1])

These seem like much better solutions to the scenario you present.
What does the REFERER check do that is not handled by the above?

At that point, the user's privacy concerns could be handled with the
meta referrer tag.

[0] 
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security#Browser_compatibility
[1] 
https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options#Browser_compatibility

-- 
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/CADhq2b4-E9tS5yqho%2BVKERE4-66XenoN_vBDWwjwNUTqPtGdAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Collin Anderson]

If we add Origin checking, could we then allow a missing referrer and 
token? (check referrer and token if no origin header)

On Tuesday, February 3, 2015 at 5:15:08 PM UTC-5, Paul McMillan wrote:
>
> The referer check is primarily there to help make users who choose not 
> to use HSTS safer. 
>
> Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP 
> page emulating your domain in an iframe on a different unencrypted 
> page, even if you only ever serve your own page from HTTPS), and then 
> post (from wherever) to your secured page. By forcing the post to come 
> from the same domain, we've made this attack significantly less 
> convenient. 
>
> I agree that it's really unfortunate that we don't have a better 
> mechanism for this in the browsers, but this still seems to be the 
> best tradeoff we have right now. 
>
> -Paul 
>
>
> On Tue, Feb 3, 2015 at 9:43 PM, Jon Dufresne  > wrote: 
> > On Tue, Feb 3, 2015 at 11:52 AM, Aymeric Augustin 
> > > wrote: 
> >> You can fix that problem by saving some authentication info in the 
> user's session, most likely with a custom auth backend — see django-sesame 
> for an example of how to do this. Then redirect immediately to an URL that 
> doesn't contain the nonce. Of course all this must happen over HTTPS to 
> reduce the likelihood of leaving the nonce in the logs of various caches or 
> reverse proxies. 
> > 
> > My application is 100% over HTTPS, HTTP traffic is not allowed. 
> > 
> > Thanks for these pointers. This may not work exactly for me, but it 
> > certainly is something interesting to think about. I'll look into it 
> > more. 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/CADhq2b6SXqY78qiNdB7BkAQUcBHzAFUON%3DY69mEddu6Q55SWdg%40mail.gmail.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/5010287a-f16e-4016-bcd5-4d5940eaf7d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Russell Keith-Magee]

On Wed, Feb 4, 2015 at 6:49 AM, frantisek holop  wrote:

> Tom Christie, 03 Feb 2015 12:53:
> > Trimming at `request.POST` or at the `Form` layer absolutely isn't
> > sensible, and a `normalize` argument is probably just overcomplicating
> > things, but I got the impression from that ticket that nobody would have
> > any great issue with someone issuing a patch with a `trim_whitespace`
> flag
> > on CharFields and TextFields.
>

Jacob specifically said a good patch for this feature would be considered
when he wontfixed #6362.


> i'd be more than happy with a flag like that, provided
> it is True by default...
>

I can tell you that this *won't* happen - firstly because 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.


> i don't feel strongly about any of the solutions as
> long as i don't have to change all my models to add a
> flag i always need...
>

You wouldn't be changing it on a model - it would be on the form.

i think wontfix-ing the ticket sent the wrong
> signal, and people stopped trying to seek a consensus
> on something that is perceived as a dead-end..
>

Read the comment where #6362 was closed WONTFIX, and you'll see Jacob left
the door open for a "strip"-style approach, and specifically asked of for a
patch implementing that behavior. WONTFIX is a single flag - sometimes you
need to read the context as well.

Yours,
Russ Magee %-)

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

Re: GSOC 2015 project ideas suggestion

[Russell Keith-Magee]

On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin  wrote:

> Thank you both for the feedback. I will continue my analysis to understand
> django well and also try to contribute some patch on django if I can.
>
>
> For django URL dispatcher improvement I am also looking for some
> suggestions. Should I also look to some tool like werkzeug, webob along
> side django http, url dispatch, middleware and related stuffs. Some guide
> will help me to dig more and go to proper direction.
>

Take inspiration from wherever you can. Those patches will demonstrate
different ways of doing dispatch, and different ways to organize a stack;
in an ideal world, you should be able to use any of those techniques in
Django as well. If you can find a way to modify Django so that those
techniques can be used (either by directly using a third party package, or
by building a Django equivalent), then I'd say you've cracked the core of
the project.

Yours,
Russ Magee %-)

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

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

[frantisek holop]

Tom Christie, 03 Feb 2015 12:53:
> Trimming at `request.POST` or at the `Form` layer absolutely isn't 
> sensible, and a `normalize` argument is probably just overcomplicating 
> things, but I got the impression from that ticket that nobody would have 
> any great issue with someone issuing a patch with a `trim_whitespace` flag 
> on CharFields and TextFields.

i'd be more than happy with a flag like that, provided
it is True by default...

i don't feel strongly about any of the solutions as
long as i don't have to change all my models to add a
flag i always need...

i think wontfix-ing the ticket sent the wrong
signal, and people stopped trying to seek a consensus
on something that is perceived as a dead-end..

-f
-- 
in an atomic war, all men will be cremated equal.

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

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Paul McMillan]

The referer check is primarily there to help make users who choose not
to use HSTS safer.

Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP
page emulating your domain in an iframe on a different unencrypted
page, even if you only ever serve your own page from HTTPS), and then
post (from wherever) to your secured page. By forcing the post to come
from the same domain, we've made this attack significantly less
convenient.

I agree that it's really unfortunate that we don't have a better
mechanism for this in the browsers, but this still seems to be the
best tradeoff we have right now.

-Paul


On Tue, Feb 3, 2015 at 9:43 PM, Jon Dufresne  wrote:
> On Tue, Feb 3, 2015 at 11:52 AM, Aymeric Augustin
>  wrote:
>> You can fix that problem by saving some authentication info in the user's 
>> session, most likely with a custom auth backend — see django-sesame for an 
>> example of how to do this. Then redirect immediately to an URL that doesn't 
>> contain the nonce. Of course all this must happen over HTTPS to reduce the 
>> likelihood of leaving the nonce in the logs of various caches or reverse 
>> proxies.
>
> My application is 100% over HTTPS, HTTP traffic is not allowed.
>
> Thanks for these pointers. This may not work exactly for me, but it
> certainly is something interesting to think about. I'll look into it
> more.
>
> --
> 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/CADhq2b6SXqY78qiNdB7BkAQUcBHzAFUON%3DY69mEddu6Q55SWdg%40mail.gmail.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/CAO_YWRWosR0yePoqiQSKW2M4--ucY747smFNXcUSSQ4GnsCmag%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:52 AM, Aymeric Augustin
 wrote:
> You can fix that problem by saving some authentication info in the user's 
> session, most likely with a custom auth backend — see django-sesame for an 
> example of how to do this. Then redirect immediately to an URL that doesn't 
> contain the nonce. Of course all this must happen over HTTPS to reduce the 
> likelihood of leaving the nonce in the logs of various caches or reverse 
> proxies.

My application is 100% over HTTPS, HTTP traffic is not allowed.

Thanks for these pointers. This may not work exactly for me, but it
certainly is something interesting to think about. I'll look into it
more.

-- 
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/CADhq2b6SXqY78qiNdB7BkAQUcBHzAFUON%3DY69mEddu6Q55SWdg%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:39 AM, Aymeric Augustin
 wrote:
> Le 3 févr. 2015 à 16:54, Jon Dufresne  a écrit :
>> Assuming this MITM already has the correct CSRF value, what is
>> stopping this MITM from adding a REFERER to the HTTPS request?
>
> While MITM of HTTP is trivial, MITM of HTTPS isn't possible (under Django's 
> security model, which doesn't account for government-level attacks, etc.)

Agreed. My application is 100% over HTTPS, so why do I need the CSRF
referrer check. As you state, MITM is theoretically impossible?

However I'm referring to this comment:

> We're talking about a MITM of an HTTP connection that is then used for
> posting a form over an HTTPS connection. Check the comment in the first
> message of this thread for details.

So the MITM is over HTTP, which we both agree is trivial. This MITM
then makes an HTTPS POST request. Making a HTTPS POST request on its
own is also trivial. To circumvent the CSRF protection the MITM will
need the CSRF token as well as to set the referrer header. If the MITM
is capable of obtaining the CSRF, adding a header to a request seems
like the trivial part.

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

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

[Tom Christie]

Trimming at `request.POST` or at the `Form` layer absolutely isn't 
sensible, and a `normalize` argument is probably just overcomplicating 
things, but I got the impression from that ticket that nobody would have 
any great issue with someone issuing a patch with a `trim_whitespace` flag 
on CharFields and TextFields.

The only thing beside then to resolve would be if we'd be okay with *its 
default being True*, despite the (edge case) backward incompatibility 
that'd cause. That seems to me to be simple and desirable behavior, doesn't 
need any extra settings, and you'd only need to override that argument in 
the bizarre cases where you *don't* want to strip leading and trailing 
whitespace.

Granted that ticket's been around for an *awfully* long time, but it's only 
a case of someone actually acting on it, and seeking a consensus on a 
sensible option, so...

Cheers,

  Tom


On Tuesday, 3 February 2015 17:22:38 UTC, frantisek holop wrote:
>
> good day, 
>
> a recent technical support incident conducted remotely and 
> involving a lot of back and forth of "huh? but i have entered 
> what you sent me" left me my head scratching. 
>
> the reason turned out to be a trailing space in the username of 
> the django admin loginform (thank god for nginx's "$request_body" 
> log_format parameter). 
>
> this of course sent me on an archeological journey into the lands 
> of stackoverflow, blogs, and finally #6362 and this mailing list. 
> it has been some 5 years now since the decision on that 
> controversial ticket. 
>
> i also went through the whole emotianal rollercoaster: 
>
> how come, so many batteries are included, but when it comes to 
> this essential POST best practice, i needed in every single 
> webform i have ever made, and now i have to do it myself? 
> error-prone and not DRY. especially for the admin login form, 
> it is a usability issue. 
>
> vs 
>
> the BDFL is right, silently discarding user input is just wrong. 
> just use a package like happyforms[1], or pick a stackoverflow 
> answer and be done with it. 
>
>
> but wait, then HTML is also wrong, because it silently folds all 
> whitespace into 1 piece of space, we are all used to this.  even 
> if the user entered whitespace is saved, pushing it back onto the 
> web will silently corrupt it (unless taken care of).  i am not 
> saying this requirement does not exist for someone, somewhere, 
> but i have yet to see a site in the wild that needs this (hello, 
> ascii art people).  whitespace in fields was always reserved for 
> government sites :) 
>
>
> it seems to me that there is a vocal group (majority?) that would 
> welcome a simple switch to make whitespace go away _now_, instead 
> of waiting for that perfect solution lurking in the future along 
> the lines of a generic normalize kwarg, or a flag on _every_ 
> {Char,Text}Field on the model or overriding form.fields 
> attributes like required. 
>
> apps that need to preserve the whitespace are the exception, 
> not the rule, and that is why i would prefer not to start every 
> project by overriding BaseForm._clean_fields[2]. 
>
> so i would like to present another idea for a possibe solution, a 
> proposal i have not seen so far: to have a global setting like 
> FORM_STRIP_FIELDS=True or some such and then roughly: 
>
> diff --git a/django/forms/forms.py b/django/forms/forms.py 
> index c9b8cf2..aab737a 100644 
> --- a/django/forms/forms.py 
> +++ b/django/forms/forms.py 
> @@ -8,6 +8,7 @@ from collections import OrderedDict 
>  import copy 
>  import datetime 
>   
> +from django.conf import settings 
>  from django.core.exceptions import ValidationError, NON_FIELD_ERRORS 
>  from django.forms.fields import Field, FileField 
>  from django.forms.utils import flatatt, ErrorDict, ErrorList 
> @@ -355,6 +356,8 @@ class BaseForm(object): 
>  if isinstance(field, FileField): 
>  initial = self.initial.get(name, field.initial) 
>  value = field.clean(value, initial) 
> +elif isinstance(value, basestring) and 
> settings.FORM_STRIP_FIELDS: 
> +value = field.clean(value.strip()) 
>  else: 
>  value = field.clean(value) 
>  self.cleaned_data[name] = value 
>
> i know, it is a big hammer, but for me, it is like the timezone, 
> or csrf, i'd like to just set it, and forget about it. 
>
> -f 
>
> [1] https://pypi.python.org/pypi/happyforms 
> [2] http://chriskief.com/2012/12/21/trim-spaces-in-django-forms/ 
> -- 
> nobody can be exactly like me.  even i have trouble doing so. 
>

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

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Stephen J. Butler]

On Tue, Feb 3, 2015 at 1:39 PM, Aymeric Augustin
 wrote:
> Le 3 févr. 2015 à 16:54, Jon Dufresne  a écrit :
>> Assuming this MITM already has the correct CSRF value, what is
>> stopping this MITM from adding a REFERER to the HTTPS request?
>
> While MITM of HTTP is trivial, MITM of HTTPS isn't possible (under Django's 
> security model, which doesn't account for government-level attacks, etc.)
>
> Back then, Facebook fixed Firesheep simply by enforcing HTTPS.

This was my thought on the issue too. If someone is successfully doing
a MITM attack on your SSL sessions then CSRF is the least of your
worries. Maybe the thought is that many Django sites mix HTTP and
HTTPS session, and that the CSRF token would leak from the HTTP
session. But ISTM that you could just use different tokens for HTTP
and 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/CAD4ANxVZP%3DyEHhXgGyFPPYqKGs79c9V4HfdvVvoVBwgnVzaDQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Aymeric Augustin]

Le 3 févr. 2015 à 16:44, Jon Dufresne  a écrit :
> 
> 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.

You can fix that problem by saving some authentication info in the user's 
session, most likely with a custom auth backend — see django-sesame for an 
example of how to do this. Then redirect immediately to an URL that doesn't 
contain the nonce. Of course all this must happen over HTTPS to reduce the 
likelihood of leaving the nonce in the logs of various caches or reverse 
proxies.

Another very simple option for fixing referers is to remove all external links 
from your website. I can't say if that's an acceptable constraint for you.

Even then, you'll still leak the hostname because of DNS requests and possibly 
URLs e.g. in corporate environments that put their CA in their users' browsers 
and reverse proxy HTTPS connections...

Depending on your goals, the answer may be Tor Browser.

-- 
Aymeric.

-- 
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/3D2ECCCA-65BD-44C1-AB4F-B9BED8278A2A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Aymeric Augustin]

Le 3 févr. 2015 à 16:54, Jon Dufresne  a écrit :
> Assuming this MITM already has the correct CSRF value, what is
> stopping this MITM from adding a REFERER to the HTTPS request?

While MITM of HTTP is trivial, MITM of HTTPS isn't possible (under Django's 
security model, which doesn't account for government-level attacks, etc.)

Back then, Facebook fixed Firesheep simply by enforcing HTTPS.

-- 
Aymeric.

-- 
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/CC1448F0-9CA7-400A-9660-0FC2E3E3FC0F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Asif Saifuddin]

Thank you both for the feedback. I will continue my analysis to understand
django well and also try to contribute some patch on django if I can.


For django URL dispatcher improvement I am also looking for some
suggestions. Should I also look to some tool like werkzeug, webob along
side django http, url dispatch, middleware and related stuffs. Some guide
will help me to dig more and go to proper direction.

./auvipy

On Tue, Feb 3, 2015 at 6:13 AM, Russell Keith-Magee  wrote:

>
> On Mon, Feb 2, 2015 at 11:58 PM, Asif Saifuddin  wrote:
>
>> Hi Fabio,
>>
>> Thank you for your project ideas. I'm going to follow the ideas from
>> https://code.djangoproject.com/wiki/SummerOfCode2015
>>
>
> While this is definitely a safe option, don't rule out a
> 'not-on-the-official-list' project. The GSoC project list is a good list of
> pre-vetted projects, but it's not exhaustive. A well posed project,
> especially one relating to an old ticket, would certainly be a good
> candidate for the GSoC -  For example, multiple schema support is #6148
>
> https://code.djangoproject.com/ticket/6148
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAJxq849-9bAeo7dfoAk1XdGBFnBkykGVekRbJbs19_5UH3C1Kg%40mail.gmail.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/CAKAqTgowxrpXi2XWtf4dYH03DdBuuUeYpjjfwsA7-4nJX6xXHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

Hi frantisek,

I've also ran into a number of problems with extra whitespace in forms. 
Pretty annoying.

I also find settings pretty annoying. :) We were just talking on another 
thread [1] about the possibility of packaging packaging django.forms as a 
standalone package, but global settings are one of the main roadblocks to 
doing that.

Here are a few more possible solutions:

1.  Include some javascript on your page that .trim()s everything, maybe 
onsubmit.
2.  form = Form({k: v.strip() for k, v in request.POST.items()})
3.  Use a custom form subclass that strips the incoming values in __init__
4.  call strip() on model.save() or a pre_save signal.

[1] https://groups.google.com/d/msg/django-developers/WF3My-cZNtY/V0Z8QkQaOnAJ

Collin

On Tuesday, February 3, 2015 at 12:22:38 PM UTC-5, frantisek holop wrote:
>
> good day, 
>
> a recent technical support incident conducted remotely and 
> involving a lot of back and forth of "huh? but i have entered 
> what you sent me" left me my head scratching. 
>
> the reason turned out to be a trailing space in the username of 
> the django admin loginform (thank god for nginx's "$request_body" 
> log_format parameter). 
>
> this of course sent me on an archeological journey into the lands 
> of stackoverflow, blogs, and finally #6362 and this mailing list. 
> it has been some 5 years now since the decision on that 
> controversial ticket. 
>
> i also went through the whole emotianal rollercoaster: 
>
> how come, so many batteries are included, but when it comes to 
> this essential POST best practice, i needed in every single 
> webform i have ever made, and now i have to do it myself? 
> error-prone and not DRY. especially for the admin login form, 
> it is a usability issue. 
>
> vs 
>
> the BDFL is right, silently discarding user input is just wrong. 
> just use a package like happyforms[1], or pick a stackoverflow 
> answer and be done with it. 
>
>
> but wait, then HTML is also wrong, because it silently folds all 
> whitespace into 1 piece of space, we are all used to this.  even 
> if the user entered whitespace is saved, pushing it back onto the 
> web will silently corrupt it (unless taken care of).  i am not 
> saying this requirement does not exist for someone, somewhere, 
> but i have yet to see a site in the wild that needs this (hello, 
> ascii art people).  whitespace in fields was always reserved for 
> government sites :) 
>
>
> it seems to me that there is a vocal group (majority?) that would 
> welcome a simple switch to make whitespace go away _now_, instead 
> of waiting for that perfect solution lurking in the future along 
> the lines of a generic normalize kwarg, or a flag on _every_ 
> {Char,Text}Field on the model or overriding form.fields 
> attributes like required. 
>
> apps that need to preserve the whitespace are the exception, 
> not the rule, and that is why i would prefer not to start every 
> project by overriding BaseForm._clean_fields[2]. 
>
> so i would like to present another idea for a possibe solution, a 
> proposal i have not seen so far: to have a global setting like 
> FORM_STRIP_FIELDS=True or some such and then roughly: 
>
> diff --git a/django/forms/forms.py b/django/forms/forms.py 
> index c9b8cf2..aab737a 100644 
> --- a/django/forms/forms.py 
> +++ b/django/forms/forms.py 
> @@ -8,6 +8,7 @@ from collections import OrderedDict 
>  import copy 
>  import datetime 
>   
> +from django.conf import settings 
>  from django.core.exceptions import ValidationError, NON_FIELD_ERRORS 
>  from django.forms.fields import Field, FileField 
>  from django.forms.utils import flatatt, ErrorDict, ErrorList 
> @@ -355,6 +356,8 @@ class BaseForm(object): 
>  if isinstance(field, FileField): 
>  initial = self.initial.get(name, field.initial) 
>  value = field.clean(value, initial) 
> +elif isinstance(value, basestring) and 
> settings.FORM_STRIP_FIELDS: 
> +value = field.clean(value.strip()) 
>  else: 
>  value = field.clean(value) 
>  self.cleaned_data[name] = value 
>
> i know, it is a big hammer, but for me, it is like the timezone, 
> or csrf, i'd like to just set it, and forget about it. 
>
> -f 
>
> [1] https://pypi.python.org/pypi/happyforms 
> [2] http://chriskief.com/2012/12/21/trim-spaces-in-django-forms/ 
> -- 
> nobody can be exactly like me.  even i have trouble doing so. 
>

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

resurrecting an old friend, whitespace in forms, #6362

[frantisek holop]

good day,

a recent technical support incident conducted remotely and
involving a lot of back and forth of "huh? but i have entered
what you sent me" left me my head scratching.

the reason turned out to be a trailing space in the username of
the django admin loginform (thank god for nginx's "$request_body"
log_format parameter).

this of course sent me on an archeological journey into the lands
of stackoverflow, blogs, and finally #6362 and this mailing list.
it has been some 5 years now since the decision on that
controversial ticket.

i also went through the whole emotianal rollercoaster:

how come, so many batteries are included, but when it comes to
this essential POST best practice, i needed in every single
webform i have ever made, and now i have to do it myself?
error-prone and not DRY. especially for the admin login form,
it is a usability issue.

vs

the BDFL is right, silently discarding user input is just wrong.
just use a package like happyforms[1], or pick a stackoverflow
answer and be done with it.


but wait, then HTML is also wrong, because it silently folds all
whitespace into 1 piece of space, we are all used to this.  even
if the user entered whitespace is saved, pushing it back onto the
web will silently corrupt it (unless taken care of).  i am not
saying this requirement does not exist for someone, somewhere,
but i have yet to see a site in the wild that needs this (hello,
ascii art people).  whitespace in fields was always reserved for
government sites :)


it seems to me that there is a vocal group (majority?) that would
welcome a simple switch to make whitespace go away _now_, instead
of waiting for that perfect solution lurking in the future along
the lines of a generic normalize kwarg, or a flag on _every_
{Char,Text}Field on the model or overriding form.fields
attributes like required.

apps that need to preserve the whitespace are the exception,
not the rule, and that is why i would prefer not to start every
project by overriding BaseForm._clean_fields[2].

so i would like to present another idea for a possibe solution, a
proposal i have not seen so far: to have a global setting like
FORM_STRIP_FIELDS=True or some such and then roughly:

diff --git a/django/forms/forms.py b/django/forms/forms.py
index c9b8cf2..aab737a 100644
--- a/django/forms/forms.py
+++ b/django/forms/forms.py
@@ -8,6 +8,7 @@ from collections import OrderedDict
 import copy
 import datetime
 
+from django.conf import settings
 from django.core.exceptions import ValidationError, NON_FIELD_ERRORS
 from django.forms.fields import Field, FileField
 from django.forms.utils import flatatt, ErrorDict, ErrorList
@@ -355,6 +356,8 @@ class BaseForm(object):
 if isinstance(field, FileField):
 initial = self.initial.get(name, field.initial)
 value = field.clean(value, initial)
+elif isinstance(value, basestring) and 
settings.FORM_STRIP_FIELDS:
+value = field.clean(value.strip())
 else:
 value = field.clean(value)
 self.cleaned_data[name] = value

i know, it is a big hammer, but for me, it is like the timezone,
or csrf, i'd like to just set it, and forget about it.

-f

[1] https://pypi.python.org/pypi/happyforms
[2] http://chriskief.com/2012/12/21/trim-spaces-in-django-forms/
-- 
nobody can be exactly like me.  even i have trouble doing so.

-- 
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/20150203170856.GC19562%40obiit.org.
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 6:18 AM, Aymeric Augustin
 wrote:
> We're talking about a MITM of an HTTP connection that is then used for
> posting a form over an HTTPS connection. Check the comment in the first
> message of this thread for details.

Assuming this MITM already has the correct CSRF value, what is
stopping this MITM from adding a REFERER to the HTTPS request?

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/CADhq2b42%3D-8Lp4XtJUC4Mbn9neVoKVxGY4DNGyWb81rcxYbQ2A%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 1:31 AM, Aymeric Augustin
 wrote:
> Your request boils down to "make Django's CSRF protection of HTTPS
> pages vulnerable to MITM attacks" which isn't acceptable.

Please. That is a very straw-man like way to have a discussion.

The first thing I asked for was for additional information.
Information on why this helps with CSRF security and information on
what other web technologies use this technique. IMO, the code comment
is very limited in details for such a big jump. I'm not suggesting the
comment be expanded, just wanted to read some external links or
details. Upon receiving that information it would help me understand
if the code is doing something useful and if the code should be
modified.

> http://www.w3.org/TR/referrer-policy/#referrer-policy-states doesn't have
> a policy to send the referrer only for requests to the same origin.
>
> "Origin Only" or "Origin When Cross-Origin" are quite close and alleviate
> privacy concerns. The domain name can still leak privacy-sensitive data
> for instance if you're building a help site for people suffering from some
> illness they don't want to reveal.
>
> However, you're framing this as a security matter, which I don't get. Can
> you clarify how removing Referer headers improves security?

You're right. Privacy is a probably better term for what I'm trying to
achieve. I started with the assumption to share as little information
as possible. In my private application, 99% of the URLs are secured
behind a login. 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. Additionally, I don't want to leak
any information about my users. Including the fact that they were
using my application. Some of this is real privacy some of this is
common courtesy to the users.

Thanks for the link but I read through that document before choosing "none".

-- 
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/CADhq2b43-h5f%2BxsofcQHHiiK8%2BfMzp%3D2fSzvtNMfW7etPnSAxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Aymeric Augustin]

2015-02-03 13:10 GMT+01:00 Tim Chase :

> On 2015-02-03 10:31, Aymeric Augustin wrote:
> > Your request boils down to "make Django's CSRF protection of HTTPS
> > pages vulnerable to MITM attacks" which isn't acceptable.
>
> If you've got a MITM that can intercept HTTPS, is there any reason to
> assume they aren't in a position to spoof DNS as well, rendering the
> REFERER information immaterial?
>

We're talking about a MITM of an HTTP connection that is then used for
posting a form over an HTTPS connection. Check the comment in the first
message of this thread for details.

-- 
Aymeric.

-- 
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/CANE-7mWF5Mh_CE%3DjP8RdHUedxPSa59o4zkM%2B352Xc3iTgTRXFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Tim Chase]

On 2015-02-03 10:31, Aymeric Augustin wrote:
> Your request boils down to "make Django's CSRF protection of HTTPS
> pages vulnerable to MITM attacks" which isn't acceptable.

If you've got a MITM that can intercept HTTPS, is there any reason to
assume they aren't in a position to spoof DNS as well, rendering the
REFERER information immaterial?

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

Re: Middleware+Transactions:

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

-- 
Aymeric.


2015-02-03 9:59 GMT+01:00 Thomas Güttler :

> Dear Django developers,
>
> we currently have the following issue when upgrading from Django 1.5 to
> Django 1.6: https://github.com/etianen/django-reversion/issues/268
>
> As it seems, since Django 1.6, middlewares are not supposed to be executed
> within the same transaction as the view function is.
>
> We would like to understand why that is the default behavior now and we
> are supposed to re-organize our code base to work with that changes.
>
> What is the rationale behind middlewares not being executed within the
> same transaction as the view function?
>
> Furthermore, decorating all view functions as suggested here
> http://django-reversion.readthedocs.org/en/latest/api.
> html#revisionmiddleware is quite not feasible for large projects.
> Especially given that reversion is not the only middleware that needs to be
> executed within the same transaction as the view function. It would
> basically mean that each view function needs to be decorated potentially n
> times.
>
>
> We understand that transactions might effect performance, thus lesser
> transactions being in a transaction means faster execution. However,
> shouldn't there be the possibility to include distinct middlewares into the
> view transaction?
>
>
> Regards,
>   Thomas Güttler
>
> --
> 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/54D08DF5.8080606%40tbz-pariv.de.
> 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/CANE-7mW9NTFmMeUUrwYtGOgd_xDr2M_kpzA4r%3DbPLVy5m14ZTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Aymeric Augustin]

Hi Jon,

Your request boils down to "make Django's CSRF protection of HTTPS
pages vulnerable to MITM attacks" which isn't acceptable.

Of cours, if that's a tradeoff you want to make, you can make your own
version of CsrfViewMiddleware and put it in MIDDLEWARE_CLASSES.


2015-02-03 2:35 GMT+01:00 Jon Dufresne :

> In the interest of security, I recently started using meta referrer
> tags in my HTML [0].
>

http://www.w3.org/TR/referrer-policy/#referrer-policy-states doesn't have
a policy to send the referrer only for requests to the same origin.

"Origin Only" or "Origin When Cross-Origin" are quite close and alleviate
privacy concerns. The domain name can still leak privacy-sensitive data
for instance if you're building a help site for people suffering from some
illness they don't want to reveal.

However, you're framing this as a security matter, which I don't get. Can
you clarify how removing Referer headers improves security?

-- 
Aymeric.

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

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Raúl Cumplido]

facepalm... Just read that on the contributing guidelines, didn't know that
won't fix bugs where never reopened. So I closed it as won't fix. If the
conversation keeps going I suppose a new bug will be opened.

On Tue, Feb 3, 2015 at 8:56 AM, James Bennett  wrote:

> Please keep discussion going in this mailing-list thread, and keep in mind
> Django's policies regarding re-opening a "wontfix" ticket (which are
> essentially: don't do 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/CAL13Cg-rdh_-N9uhp4oZGZY3GKjHL_xxvEsAFDo3hQjBOmZHUQ%40mail.gmail.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/CAD1RbrqPbMY0DwwkjFvOySGuidkMinxSmr75P9aCsRPS7kavpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Middleware+Transactions:

[Thomas Güttler]

Dear Django developers,

we currently have the following issue when upgrading from Django 1.5 to Django 1.6: 
https://github.com/etianen/django-reversion/issues/268


As it seems, since Django 1.6, middlewares are not supposed to be executed within the same transaction as the view 
function is.


We would like to understand why that is the default behavior now and we are supposed to re-organize our code base to 
work with that changes.


What is the rationale behind middlewares not being executed within the same 
transaction as the view function?

Furthermore, decorating all view functions as suggested here 
http://django-reversion.readthedocs.org/en/latest/api.html#revisionmiddleware is quite not feasible for large projects. 
Especially given that reversion is not the only middleware that needs to be executed within the same transaction as the 
view function. It would basically mean that each view function needs to be decorated potentially n times.



We understand that transactions might effect performance, thus lesser transactions being in a transaction means faster 
execution. However, shouldn't there be the possibility to include distinct middlewares into the view transaction?



Regards,
  Thomas Güttler

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

Re: CSRF REASON_NO_REFERER with meta referrer tags

[James Bennett]

Please keep discussion going in this mailing-list thread, and keep in mind
Django's policies regarding re-opening a "wontfix" ticket (which are
essentially: don't do 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/CAL13Cg-rdh_-N9uhp4oZGZY3GKjHL_xxvEsAFDo3hQjBOmZHUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Raúl Cumplido]

Hi Jon,

I've reopened the bug so we have a new discussion. I think the things have
changed slightly in the last two years.

Thanks,
Raul

On Tue, Feb 3, 2015 at 2:29 AM, Karen Tracey  wrote:

> This has bee brought up before, see:
> https://code.djangoproject.com/ticket/16870
>
> I am not aware of any change in this area that would affect the decision
> made in that ticket.
>
> --
> 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/CACS9rafr6f01-9c7vBNprnz1CTJGgOUyZvfSbOw_da0b_4i4%2BQ%40mail.gmail.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/CAD1RbrpTAvR_EXmPHkz-vq7JjJGCDJySW7ogrnsvzmi%2BhNS31Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8a and geodjango on windows 7, AttributeError: function 'GDALAllRegister' not found

[Claude Paroz]

Le lundi 2 février 2015 17:30:23 UTC+1, mattxbart a écrit :
>
> Hi all,
> I had a working 1.7.4 (using geodjango) on windows 7 install, no issues. 
> I'm using osgeo4w to manage all the gdal/gis libraries. When I install the 
> django 1.8a release or off git master, I get the following traceback:
>
> $ ./manage.py shell
> Traceback (most recent call last):
>  ...
> register_all = void_output(lgdal.GDALAllRegister, [])
>   File "c:\Python27\lib\ctypes\__init__.py", line 378, in __getattr__
> func = self.__getitem__(name)
>   File "c:\Python27\lib\ctypes\__init__.py", line 383, in __getitem__
> func = self._FuncPtr((name_or_ordinal, self))
> AttributeError: function 'GDALAllRegister' not found
>
> I've installed all 32b libs, looks like something in the new raster 
> functionality? How do I get this working?
>

 Hi,

This sort of issues are better handled through a ticket. Also please try to 
provide the installed versions of the geo libs, if possible.
https://code.djangoproject.com/newticket

Claude

-- 
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/880e54fa-ad55-48fc-b969-83658d2a10bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.