On Mon, Nov 5, 2012 at 6:37 PM, Marti Raudsepp <marti@juffo.org> wrote:
On Mon, Nov 5, 2012 at 7:11 PM, Magnus Hagander <magnus@hagander.net> wrote: > That seems like it would be the result of a patch I applied earlier today. > It does appear we need a better error message for this case.
Maybe we should have a cookie test prior to the registration/login form, so people are warned before they are asked to input any information?
That would probably not be a horrible idea. However, the first thing we should do is to set up a better error message. There appears to be a setting for it (CSRF_FAILURE_VIEW) already, so we should just define that one.
Do you want to take a stab at that, or should I?
> Not entirely sure why it shows up though, since the form appears correct. > Are you by any chance blocking cookies for the domain? If I do that, I get > the same error...
I tried signing up as testuser123 and for some reason it redirects me back to insecure http:// from the secure address.
So it turns out that secure password reset was snake oil all along -- CSRF enforcement only made the problem obvious.
The cause is in pgweb.account.urls:
(r'^reset/$', 'account.views.resetpwd'), ^ has @ssl_required decorator
(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$', 'django.contrib.auth.views.password_reset_confirm', ^ points directly to the Django view, which doesn't have @ssl_required
Oh, cute. That's certainly broken.
I guess the proper way to deal with it is to define our own view that just has the @ssl_required decorator and then calls the django default view directly.