doc/bugs/login_problem_redux.mdwn

   1 Following up on [[login_problem]], there's still some problems mixing https
   2 and http logins on sites that allow both and don't redirect http to https.
   3
   4 > I think the only good solution to this is to configure web servers to
   5 > redirect http to https, which is outside the scope of the ikiwiki
   6 > software (but would be a useful configuration change on sites like
   7 > ikiwiki.info). Redirecting from CGI code is problematic because
   8 > reverse-proxies are a thing; see below. --[[smcv]]
   9
  10 If the user logs in on https first, their cookie is https-only. If they
  11 then open the http site and do something that needs them logged in, it will
  12 try to log them in again. But, the https-only cookie is apparently not
  13 replaced by the http login cookie. The login will "succeed", but the cookie
  14 is inaccessible over https and so they'll not be really logged in.
  15
  16 > Mitigation: If you have a browser-trusted certificate (which lots of
  17 > people do now, because Let's Encrypt exists), setting the `cgiurl` to
  18 > `https://...` will result in the CGI (which is the only part that
  19 > needs cookies) being accessed via https whenever the user follows
  20 > links from static content.
  21 > (`test_site4_cgi_is_secure_static_content_doesnt_have_to_be` in
  22 > `t/relativity.t`.)
  23 >
  24 > In the past I've wondered whether to add a distinction between
  25 > authenticating and unauthenticating CGI URLs, so that on sites that
  26 > don't particularly care about eavesdropping, anonymous/read-only actions
  27 > like `?do=goto` can go via `http`, but write actions and actions that
  28 > are usually authenticated like `?do=edit` go via `https`. However, in
  29 > 2018 with Let's Encrypt widely available, it seems reasonable to just
  30 > use `https` for all CGI accesses.
  31 > --[[smcv]]
  32
  33 I think that the only fix for this is make the login page redirect from
  34 http to https, and for it to return to the https version of the page that
  35 prompted the login. --[[Joey]]
  36
  37 > Redirecting the login page from http to https inside ikiwiki.cgi is
  38 > problematic, because ikiwiki can't reliably know whether it was already
  39 > accessed via https. If there is a reverse-proxy in use but the site admin
  40 > has not set the `reverse_proxy` option (which is not *always* necessary
  41 > even behind reverse proxies AIUI, and I suspect some reverse-proxied sites
  42 > haven't set it correctly), then ikiwiki.cgi would infinitely redirect back
  43 > to itself.
  44 >
  45 > For example, suppose your frontend web server is example.com and your
  46 > ikiwiki backend is 127.0.0.1:8080.
  47 >
  48 > * frontend web server sees an access to http://example.com/ikiwiki.cgi
  49 > * frontend web server reverse-proxies it to http://127.0.0.1:8080/ikiwiki.cgi
  50 > * backend web server invokes ikiwiki.cgi with `HTTPS` environment variable
  51 >   undefined
  52 > * ikiwiki.cgi thinks "I'm being accessed via plain http" (this time correctly,
  53 >   as it happens)
  54 > * ikiwiki.cgi sends a redirect to https://example.com/ikiwiki.cgi
  55 > * {1} web browser follows redirect
  56 > * frontend web server sees an access to https://example.com/ikiwiki.cgi
  57 > * frontend web server reverse-proxies it to http://127.0.0.1:8080/ikiwiki.cgi
  58 > * backend web server invokes ikiwiki.cgi with `HTTPS` environment variable
  59 >   undefined
  60 > * ikiwiki.cgi thinks "I'm being accessed via plain http" (this time incorrectly!)
  61 > * ikiwiki.cgi sends a redirect to https://example.com/ikiwiki.cgi
  62 > * goto {1}
  63 >
  64 > I think this redirection is better achieved via web server configuration, like
  65 > the Apache configuration set up by `redirect_to_https: 1` in
  66 > [ikiwiki-hosting](https://ikiwiki-hosting.branchable.com/).
  67 >
  68 > If you change ikiwiki's behaviour in this area, please add test-cases to
  69 > `t/relativity.t` to cover the cases that changed.
  70 >
  71 > --[[smcv]]