Re: [GENERAL] Error registering at postgresql.org
| От | Magnus Hagander |
|---|---|
| Тема | Re: [GENERAL] Error registering at postgresql.org |
| Дата | |
| Msg-id | CABUevExgwjPo8eYy0AL0NiqbVoE9jN2rBNN_ZU_GQJ3-3WfXPw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] Error registering at postgresql.org (Marti Raudsepp <marti@juffo.org>) |
| Ответы |
Re: [GENERAL] Error registering at postgresql.org
|
| Список | pgsql-www |
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:Maybe we should have a cookie test prior to the registration/login
> 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.
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.I tried signing up as testuser123 and for some reason it redirects me
> Are you by any chance blocking cookies for the domain? If I do that, I get
> the same error...
back to insecure http:// from the secure address.
% wget https://www.postgresql.org/account/reset/XXXX/
--2012-11-05 19:32:35-- https://www.postgresql.org/account/reset/XXXX/
HTTP request sent, awaiting response... 302 Found
Location: http://www.postgresql.org/account/reset/XXXX/ [following]
--2012-11-05 19:32:36-- http://www.postgresql.org/account/reset/XXXX/
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.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
В списке pgsql-www по дате отправления: