doc/bugs/login_problem.mdwn

   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.
   6
   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
   9 there.)
  10
  11 I have not managed to reproduce the problem myself, using firefox,
  12 firefox-esr, or chromium. --[[Joey]]
  13
  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?
  17 >
  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.
  20 > --[[Joey]]
  21 >
  22 > The reason the edit form is able to be displayed is that emailauth
  23 > sets up a session, in getsession(), and that $session is used for the
  24 > remainder of that cgi call. But, a cookie for that session is not stored
  25 > in the browser in this case. Ikiwiki *does* send a session cookie, but
  26 > the browser seems to not let an existing https-only session cookie be
  27 > replaced by a new session cookie that can be used with http. (If the
  28 > emailed link, generated on https is opened in a different browser, this
  29 > problem doesn't happen.) There may have been a browser behavior change
  30 > here?
  31 >
  32 > So what to do about this? Sites with the problem have `redirect_to_https: 0`
  33 > and the cgiurl is http not https. So when emailauth generates the url
  34 > with `cgiurl_abs`, it's a http url, even if the user got to that point
  35 > using https.
  36 >
  37 > I suppose that emailauth could look at `$ENV{HTTPS}` same as
  38 > printheader() does, to detect this case, and rewrite the cgiurl as a
  39 > https url. Or, printheader() could just not set "-secure" on the cookie,
  40 > but that does degrade security as MITM can then steal the cookie you're
  41 > using on a https site.
  42 >
  43 > Of course, the easy workaround, increasingly a good idea anyway, is to
  44 > enable `redirect_to_https`.. --[[Joey]]
  45
  46 > One of the users also reported a problem with password reset, and
  47 > indeed, passwordauth is another caller of `cgiurl_abs`. (The only other
  48 > caller, notifyemail, is probably fine.) The emailed password reset link
  49 > also should be https if the user was using https. So, let's add a
  50 > `cgiurl_abs_samescheme` that both can use. --[[Joey]]
  51
  52 [[fixed|done]].. At least I hope that was the thing actually preventing most
  53 of the people from logging in. --[[Joey]]