@csrf_protect annoying on django.contrib.auth.views.login

[mdj2]

Is there a reason django.contrib.auth.views.login should be decorated 
with csrf_protect? It results in annoying behavior, in the following 
scenario:

In a browser window (Window1), go to the login page.
In another browser window (Window2), go to the login page, and actually 
login, then logout.
Back in Window1, fill in your credentials, and try to login. You get a 403.

It seems like django.contrib.auth.views.login should be decorated with 
csrf_exempt instead. Are there any major security implications?

-- 
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/2e92d25a-58dc-4f9a-b2d0-ad9ba0426776%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: @csrf_protect annoying on django.contrib.auth.views.login

[mdj2]

I was not aware of that kind of attack. It's pretty clever.

Thanks for the info and the workaround JS.

On Wednesday, July 1, 2015 at 4:29:32 PM UTC-7, Collin Anderson wrote:
>
> Hi,
>
> This is the best reason I could find:
>
> http://security.stackexchange.com/questions/62769/must-login-and-logout-action-have-csrf-protection
>
> One thing that's going on here is that the csrftoken changes every time 
> someone logs in, so the old login page now has a stale token. The changing 
> csrf token has bitten me a bunch of times. I've gotten around it by using 
> javascript to correct the token when submitting the form.
>
> $(document).on('submit', 'form[method=post]', function() { 
>   $(this.csrfmiddlewaretoken).val(document.cookie.match(
> 'csrftoken=([a-zA-Z0-9]{32})')[1])
> })
>
> Collin
>
> On Wednesday, July 1, 2015 at 7:13:42 PM UTC-4, md...@pdx.edu wrote:
>>
>> Is there a reason django.contrib.auth.views.login should be decorated 
>> with csrf_protect? It results in annoying behavior, in the following 
>> scenario:
>>
>> In a browser window (Window1), go to the login page.
>> In another browser window (Window2), go to the login page, and actually 
>> login, then logout.
>> Back in Window1, fill in your credentials, and try to login. You get a 
>> 403.
>>
>> It seems like django.contrib.auth.views.login should be decorated with 
>> csrf_exempt instead. Are there any major security implications?
>>
>

-- 
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/e8a54634-a08b-4dbd-8df9-d5e1c7ab4b4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

djangoproject.org not resolving

[mdj2]

djangoproject.org does not redirect to djangoproject.com. The org domain 
appears to be owned by the Django Software Foundation, and the nameservers 
are the same as djangoproject.com. Is there a reason a redirect is not 
setup?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5844f7d5-2bf5-47ec-8935-7841720a6d06%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Support byte range requests in django.views.static.serve

[mdj2]

Is the Django community interested in supporting HTTP range requests in 
django.views.static.serve
?

The primary benefit I see is that it makes files served up for  and 
 "seek-able" with the django server. This generally isn't a problem 
for small files (except in 
Chrome), 
but becomes an issue for larger ones.

Werkzeug has a function that parses the range 
header,
 
which I used to support range requests in a Django application. I estimate 
that robust support for HTTP range requests would cost <300 lines of code, 
plus tests.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/37cdec22-e19d-4843-a3e4-a6b1e1bfa86e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support byte range requests in django.views.static.serve

[mdj2]

Apparently, I don't know how to use Google groups. I think I sent something 
directly to Russell, and it wasn't posted here. Oops. Here it is again 
(from memory):

It takes more than just running gunicorn. You'd have to setup Apache or 
Nginx in front. And if Django needs to handle the request first (for 
authentication purposes), then you would have to configure something like 
xsendfile as well.

The Django server was included "so you can develop things rapidly, without 
having to deal with configuring a production server". If you happen to be 
developing with HTML 5 video and audio, the Django server doesn't live up 
to its stated goal.

On Sunday, April 13, 2014 8:43:56 PM UTC-7, Alex_Gaynor wrote:
>
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> I'd be +1 on doing this -- I know we've always said that Django's static 
> serve isn't for production use, but as video and audio are increasingly 
> common on the web, Django should support them seemlessly.
>
> Alex
>
> PS: I'm of course open to other ways of supporting these, such as using 
> Twisted for static file serving. (0.5 wink ;-)
>
> -BEGIN PGP SIGNATURE- 
> Version: Mailvelope v0.8.0 
> Comment: Email security by Mailvelope - http://www.mailvelope.com 
>
> wsFcBAEBCAAQBQJTS1l0CRASX1xn3+lAhAAAzhAP/RJ5RA4zXF8/sog+snpf
> ZhxObrYh04irkjQDcV7Jzs80tsgTWuhZBQgrlPR9ESfsOcIDSTStGGZsDFyR
> y7VnFCa0RFsE/jXi3tkig2VFiK9cNIYbRNyzwETiOVBoiUeP52nq/TUVkAOD
> UUmLbV9wdEXFAc/i/dkgJk4HxIYjzqURMFJ5S+XPi/6jwEF9Ds16ORONPY9o
> nTC9c1auzra91HqxDs/n5OTg8L9p80y3QRrsHx2vrCP7R1yPyteuqeWVd1Lk
> zqvj5/bwHRcMR0Q/oXnjvG3UJuOf+nx3s2o6hFoAHiVfXsrIMOUv/PTnr+Ck
> ayj7+lrRr+wpOr0rfgARFpLv1GggNaug2ZnFfLVGJZ+VGBJ1nWmDq+j8bMEI
> zUEPBUw+BxDWoQXdNUacl9J16YerUw5aaTEzTppwNg65UU6YobvaToSe5Dqe
> nto/8dW/JBXC7YeRCXSxaOoJnX6A7rnI7Typr2pB6PcWPjevSZYxrXuf1Cf3
> YG/5fQ6FRbuh2SevQGO634RiEkr/Z6DbDlEINCBvLPx692aJ31IFOmJSF+ds
> AtDYeJjzDf6oKVdqlMJ0mAft1BIjUzpOGvgMjhQpss4cZBDWHID1T5ZUHdVL
> H7Q+0JAskdC8Oa6BrveGydZZfcQpYyy1sghxwxaXqwKguc8gTwcw2Wsx59un
> waxF 
> =Ofgw 
> -END PGP SIGNATURE- 
>
>
> On Sun, Apr 13, 2014 at 11:30 PM, > wrote:
>
>> Is the Django community interested in supporting HTTP range requests in 
>> django.views.static.serve
>> ?
>>
>> The primary benefit I see is that it makes files served up for  
>> and  "seek-able" with the django server. This generally isn't a 
>> problem for small files (except in 
>> Chrome),
>>  
>> but becomes an issue for larger ones.
>>
>> Werkzeug has a function that parses the range 
>> header,
>>  
>> which I used to support range requests in a Django application. I estimate 
>> that robust support for HTTP range requests would cost <300 lines of code, 
>> plus tests.
>>  
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-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/37cdec22-e19d-4843-a3e4-a6b1e1bfa86e%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> "I disapprove of what you say, but I will defend to the death your right 
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6839518c-52f6-49f8-838b-6696f215345a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support byte range requests in django.views.static.serve

[mdj2]

I made a ticket in the hopes of drawing more attention to the patch:

https://code.djangoproject.com/ticket/23382

On Sunday, April 13, 2014 8:30:37 PM UTC-7, md...@pdx.edu wrote:
>
> Is the Django community interested in supporting HTTP range requests in 
> django.views.static.serve 
> ?
>
> The primary benefit I see is that it makes files served up for  and 
>  "seek-able" with the django server. This generally isn't a problem 
> for small files (except in Chrome 
> ), 
> but becomes an issue for larger ones.
>
> Werkzeug has a function that parses the range header 
> ,
>  
> which I used to support range requests in a Django application. I estimate 
> that robust support for HTTP range requests would cost <300 lines of code, 
> plus tests.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd2ee88a-12df-4cad-8b4e-b8c26f5c77e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.