1 For around 2 weeks, I've been getting an increasing quantity of nonspecific
2 reports from users of login problems on ikiwiki sites, mostly joeyh.name
3 and git-annex.branchable.com. A few users are still logging in
4 successfully, but it seems to be hitting many users; post volume has gone
5 down more than holidays would explain.
7 It doesn't seem limited to any login method; email and password have both
8 been said not to work. (Openid too, but could be openid provider problem
11 I have not managed to reproduce the problem myself, using firefox,
12 firefox-esr, or chromium. --[[Joey]]
14 > Otto Kekäläinen described to me a problem where email login to post a
15 > comment seemed to work; it displayed the comment edit form; but posting
16 > the form went back to the login page. Cookie problem?
18 > Ok, to reproduce the problem: Log into joeyh.name using https. The email
19 > login link is a http link. The session cookie was set https-only.
22 > So what to do about this? Sites with the problem have `redirect_to_https: 0`
23 > and the cgiurl is http not https. So when emailauth generates the url,
24 > it's a http url, even if the user got to that point using https.
26 > I suppose that emailauth could look at `$ENV{HTTPS}` same as
27 > printheader() does, to detect this case, and rewrite the cgiurl as a
28 > https url. Or, printheader() could just not set "-secure" on the cookie,
29 > but that does degrade security as MITM can then steal the cookie you're
30 > using on a https site.
32 > Of course, the easy workaround, increasingly a good idea anyway, is to
33 > enable `redirect_to_https`.. --[[Joey]]