reports from users of login problems on ikiwiki sites, mostly joeyh.name
and git-annex.branchable.com. A few users are still logging in
successfully, but it seems to be hitting many users; post volume has gone
-down more than holidays would explain. --[[Joey]]
+down more than holidays would explain.
It doesn't seem limited to any login method; email and password have both
been said not to work. (Openid too, but could be openid provider problem
there.)
-After a few tries
-I seem to have reproduced the problem with email login; I ended up at a
-"Error: login failed, perhaps you need to turn on cookies?"
-page but my browser had an ikiwiki session cookie. And,
-looking in the session database file, the cookie id was in there. Then I
-went to "/do=prefs" in the same browser, and I was actually already
-logged in.
+I have not managed to reproduce the problem myself, using firefox,
+firefox-esr, or chromium. --[[Joey]]
-That points at a problem with the "postsignin" redirect;
-if the session does not get a postsignin url set, it can error out that way
-despite being logged in.
+> Otto Kekäläinen described to me a problem where email login to post a
+> comment seemed to work; it displayed the comment edit form; but posting
+> the form went back to the login page. Cookie problem?
+>
+> 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
+> 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
+> https url. Or, printheader() could just not set "-secure" on the cookie,
+> but that does degrade security as MITM can then steal the cookie you're
+> using on a https site.
+>
+> Of course, the easy workaround, increasingly a good idea anyway, is to
+> enable `redirect_to_https`.. --[[Joey]]
-Reproducing again, I posted the login form, and before clicking on the
-login link, looked at the session.db -- it contained an entry for my session,
-but without a postsignin url.
+> 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]]
- $ strings sessions.db
- $D = {'_SESSION_ID' => 'xxx','_SESSION_REMOTE_ADDR' => 'yyy','_SESSION_ATIME' => 1515106022,'_SESSION_CTIME' => 1515105990};;$D
-
-The postsignin url is certianly getting set at other times though,
-and why would this have only recently started to affect lots of users?
+[[fixed|done]].. At least I hope that was the thing actually preventing most
+of the people from logging in. --[[Joey]]