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

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

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

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

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

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 >

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

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 fir

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

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

djangoproject.org not resolving

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 Googl