]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/bugs/login_problem_redux.mdwn
update for rename of recentchanges.mdwn to json.tl.ph.mdwn
[git.ikiwiki.info.git] / 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.
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]]
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.
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]]
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]]
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]]