aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2018-01-05 11:40:18 -0400
committerJoey Hess <joeyh@joeyh.name>2018-01-05 11:59:35 -0400
commita79ab9ed186112056d7f60e41e8d0760c2cc13f5 (patch)
treecd0bb678038afd22e54b875dd19e13405a5719a5
parent71064e3af6638616659ed1319ec78f9692ba9fde (diff)
downloadikiwiki-a79ab9ed186112056d7f60e41e8d0760c2cc13f5.tar
ikiwiki-a79ab9ed186112056d7f60e41e8d0760c2cc13f5.tar.gz
add and use cgiurl_abs_samescheme
* 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. Not entirely happy with this approach, but I don't currently see a better one. I have not verified that the passwordauth change fixes any problem, other than the user getting a http link when they were using https. The emailauth problem is verified fixed by this commit. This commit was sponsored by Michael Magin.
-rw-r--r--IkiWiki.pm13
-rw-r--r--IkiWiki/Plugin/emailauth.pm2
-rw-r--r--IkiWiki/Plugin/passwordauth.pm2
-rw-r--r--debian/changelog4
-rw-r--r--doc/bugs/login_problem.mdwn26
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]]