diff options
| author | Joey Hess <joeyh@joeyh.name> | 2018-01-05 11:17:11 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2018-01-05 11:17:11 -0400 |
| commit | 71064e3af6638616659ed1319ec78f9692ba9fde (patch) | |
| tree | 8bfcc4acc69fad29f4430547fb187fb344dabfae | |
| parent | 76ff547344de435adfb97cd1c8046f6cadf0ccd3 (diff) | |
| download | ikiwiki-71064e3af6638616659ed1319ec78f9692ba9fde.tar ikiwiki-71064e3af6638616659ed1319ec78f9692ba9fde.tar.gz | |
how to fix?
| -rw-r--r-- | doc/bugs/login_problem.mdwn | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/doc/bugs/login_problem.mdwn b/doc/bugs/login_problem.mdwn index b9f70d755..0946a238f 100644 --- a/doc/bugs/login_problem.mdwn +++ b/doc/bugs/login_problem.mdwn @@ -18,3 +18,16 @@ firefox-esr, or chromium. --[[Joey]] > 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]] + +> 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, +> 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]] |