diff options
| -rw-r--r-- | IkiWiki.pm | 13 | ||||
| -rw-r--r-- | IkiWiki/Plugin/emailauth.pm | 2 | ||||
| -rw-r--r-- | IkiWiki/Plugin/passwordauth.pm | 2 | ||||
| -rw-r--r-- | debian/changelog | 4 | ||||
| -rw-r--r-- | doc/bugs/login_problem.mdwn | 26 |
5 files changed, 42 insertions, 5 deletions
diff --git a/IkiWiki.pm b/IkiWiki.pm index 1eda16da1..0d87242eb 100644 --- a/IkiWiki.pm +++ b/IkiWiki.pm @@ -1232,6 +1232,19 @@ sub cgiurl_abs (@) { URI->new_abs(cgiurl(@_), $config{cgiurl}); } +# Same as cgiurl_abs, but when the user connected using https, +# will be a https url even if the cgiurl is normally a http url. +# +# This should be used for anything involving emailing a login link, +# because a https session cookie will not be sent over http. +sub cgiurl_abs_samescheme (@) { + my $u=cgiurl_abs(@_); + if (($ENV{HTTPS} && lc $ENV{HTTPS} ne "off")) { + $u=~s/^http:/https:/i; + } + return $u +} + sub baseurl (;$) { my $page=shift; diff --git a/IkiWiki/Plugin/emailauth.pm b/IkiWiki/Plugin/emailauth.pm index 9c595dc86..44311400a 100644 --- a/IkiWiki/Plugin/emailauth.pm +++ b/IkiWiki/Plugin/emailauth.pm @@ -76,7 +76,7 @@ sub email_auth ($$$$) { $template->param( wikiname => $config{wikiname}, # Intentionally using short field names to keep link short. - authurl => IkiWiki::cgiurl_abs( + authurl => IkiWiki::cgiurl_abs_samescheme( 'e' => $email, 'v' => $token, ), diff --git a/IkiWiki/Plugin/passwordauth.pm b/IkiWiki/Plugin/passwordauth.pm index 8d99cf2f6..cfa3ad418 100644 --- a/IkiWiki/Plugin/passwordauth.pm +++ b/IkiWiki/Plugin/passwordauth.pm @@ -358,7 +358,7 @@ sub formbuilder (@) { my $template=template("passwordmail.tmpl"); $template->param( user_name => $user_name, - passwordurl => IkiWiki::cgiurl_abs( + passwordurl => IkiWiki::cgiurl_abs_samescheme( 'do' => "reset", 'name' => $user_name, 'token' => $token, diff --git a/debian/changelog b/debian/changelog index 63e5f61d6..6cf509f9d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,9 @@ ikiwiki (3.20171002) UNRELEASED; urgency=medium + * emailauth: Fix cookie problem when user is on https and the cgiurl + uses http, by making the emailed login link use https. + * passwordauth: Use https for emailed password reset link when user + is on https. * Updated German basewiki and directives translation from Sebastian Kuhnert. diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn index 0946a238f..14e3fb325 100644 --- a/doc/bugs/login_problem.mdwn +++ b/doc/bugs/login_problem.mdwn @@ -18,10 +18,21 @@ firefox-esr, or chromium. --[[Joey]] > Ok, to reproduce the problem: Log into joeyh.name using https. The email > login link is a http link. The session cookie was set https-only. > --[[Joey]] - +> +> The reason the edit form is able to be displayed is that emailauth +> sets up a session, in getsession(), and that $session is used for the +> remainder of that cgi call. But, a cookie for that session is not stored +> in the browser in this case. Ikiwiki *does* send a session cookie, but +> the browser seems to not let an existing https-only session cookie be +> replaced by a new session cookie that can be used with http. (If the +> emailed link, generated on https is opened in a different browser, this +> problem doesn't happen.) There may have been a browser behavior change +> here? +> > So what to do about this? Sites with the problem have `redirect_to_https: 0` -> and the cgiurl is http not https. So when emailauth generates the url, -> it's a http url, even if the user got to that point using https. +> and the cgiurl is http not https. So when emailauth generates the url +> with `cgiurl_abs`, it's a http url, even if the user got to that point +> using https. > > I suppose that emailauth could look at `$ENV{HTTPS}` same as > printheader() does, to detect this case, and rewrite the cgiurl as a @@ -31,3 +42,12 @@ firefox-esr, or chromium. --[[Joey]] > > Of course, the easy workaround, increasingly a good idea anyway, is to > enable `redirect_to_https`.. --[[Joey]] + +> One of the users also reported a problem with password reset, and +> indeed, passwordauth is another caller of `cgiurl_abs`. (The only other +> caller, notifyemail, is probably fine.) The emailed password reset link +> also should be https if the user was using https. So, let's add a +> `cgiurl_abs_samescheme` that both can use. --[[Joey]] + +[[fixed|done]].. At least I hope that was the thing actually preventing most +of the people from logging in. --[[Joey]] |