X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/71fa036270e4c202ee19be60b81993fb6e7cb4cb..8806a9795116e73ec851dfea89af45a786fbe6da:/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index 63fd3d11d..20d22b9ab 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -56,3 +56,157 @@ becoming a problem for me. Is there anything I can do here? --[[Perry]] > absolute urls that have been fixed since Brian filed the bug. --[[Joey]] [[wishlist]] + +---- + +[[!toggle id="smcv-https" text="Some discussion of a rejected implementation, smcv/https."]] +[[!toggleable id="smcv-https" text=""" + +[[!template id=gitbranch branch=smcv/https author="[[smcv]]"]] + +For a while I've been using a configuration where each wiki has a HTTP and +a HTTPS mirror, and updating one automatically updates the other, but +that seems unnecessarily complicated. My `https` branch adds `https_url` +and `https_cgiurl` config options which can be used to provide a HTTPS +variant of an existing site; the CGI script automatically detects whether +it was accessed over HTTPS and switches to the other one. + +This required some refactoring, which might be worth merging even if +you don't like my approach: + +* change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if + called with no parameters, and change all plugins to indirect through it + (then I only need to change that one function for the HTTPS hack) + +* `IkiWiki::baseurl` already has similar behaviour, so change nearly all + references to the `$config{url}` to call `baseurl` (a couple of references + specifically wanted the top-level public URL for Google or Blogspam rather + than a URL for the user's browser, so I left those alone) + +--[[smcv]] + +> The justification for your patch seems to be wanting to use a different +> domain, like secure.foo.com, for https? Can you really not just configure +> both url and cgiurl to use `https://secure.foo.com/...` and rely on +> relative links to keep users of `http://insecure.foo.com/` on http until +> they need to use the cgi? + +>> My problem with that is that uses of the CGI aren't all equal (and that +>> the CA model is broken). You could put CGI uses in two classes: +>> +>> - websetup and other "serious" things (for the sites I'm running, which +>> aren't very wiki-like, editing pages is also in this class). +>> I'd like to be able to let privileged users log in over +>> https with httpauth (or possibly even a client certificate), and I don't +>> mind teaching these few people how to do the necessary contortions to +>> enable something like CACert. +>> +>> - Random users making limited use of the CGI: do=goto, do=404, and +>> commenting with an OpenID. I don't think it's realistic to expect +>> users to jump through all the CA hoops to get CACert installed for that, +>> which leaves their browsers being actively obstructive, unless I either +>> pay the CA tax (per subdomain) to get "real" certificates, or use plain +>> http. +>> +>> On a more wiki-like wiki, the second group would include normal page edits. +>> +>>> I see your use case. It still seems to me that for the more common +>>> case where CA tax has been paid (getting a cert that is valid for +>>> multiple subdomains should be doable?), having anything going through the +>>> cgiurl upgrade to https would be ok. In that case, http is just an +>>> optimisation for low-value, high-aggregate-bandwidth type uses, so a +>>> little extra https on the side is not a big deal. --[[Joey]] +>> +>> Perhaps I'm doing this backwards, and instead of having the master +>> `url`/`cgiurl` be the HTTP version and providing tweakables to override +>> these with HTTPS, I should be overriding particular uses to plain HTTP... +>> +>> --[[smcv]] +>>> +>>> Maybe, or I wonder if you could just use RewriteEngine for such selective +>>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]] + +> I'm unconvinced. +> +> `Ikiwiki::baseurl()."foo"` just seems to be asking for trouble, +> ie being accidentially written as `IkiWiki::baseurl("foo")`, +> which will fail when foo is not a page, but some file. + +>> That's a good point. --s + +> I see multiple places (inline.pm, meta.pm, poll.pm, recentchanges.pm) +> where it will now put the https url into a static page if the build +> happens to be done by the cgi accessed via https, but not otherwise. +> I would rather not have to audit for such problems going forward. + +>> Yes, that's a problem with this approach (either way round). Perhaps +>> making it easier to run two mostly-synched copies like I was previously +>> doing is the only solution... --s + +"""]] + +---- + +[[!template id=gitbranch branch=smcv/ready/localurl author="[[smcv]]"]] +[[!tag patch]] + +OK, here's an alternative approach, closer in spirit to what was initially +requested. I included a regression test for `urlto`, `baseurl` and `cgiurl`, +now that they have slightly more complex behaviour. + +The idea is that in the common case, the CGI and the pages will reside on the +same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`, +`/bugs/done`) to refer to each other. Most redirects, form actions, links etc. +can safely use this form rather than the fully-absolute URL. + +The initial version of the branch had config options `local_url` and +`local_cgiurl`, but they're now automatically computed by checking +whether `url` and `cgiurl` are on the same server with the the same URL +scheme. In theory you could use things like `//static.example.com/wiki/` +and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https +while switching server, but I don't know how consistently browsers +suppot that. + +"local" here is short for "locally valid", because these URLs are neither +fully relative nor fully absolute, and there doesn't seem to be a good name +for them... + +I've tested this on a demo website with the CGI enabled, and it seems to +work nicely (there might be bugs in some plugins, I didn't try all of them). +The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable +`httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log +in via that, links all end up in the HTTPS version. + +New API added by this branch: + +* `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}` + +* `IkiWiki::baseurl` has a new second argument which works like the + third argument of `urlto` + +* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1` + +* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters + except `cgiurl` and/or `local_cgiurl` + +Bugs: + +* I don't think anything except `openid` calls `cgiurl` without also + passing in `local_cgiurl => 1`, so perhaps that should be the default; + `openid` uses the `cgiurl` named parameter anyway, so there doesn't even + necessarily need to be a way to force absolute URLs? Any other module + that really needs an absolute URL could use + `cgiurl(cgiurl => $config{cgiurl}, ...)`, + although that does look a bit strange + +* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being + exported? Perhaps also `IkiWiki::baseurl`? + +* Or, to reduce use of the unexported `baseurl` function, it might make + sense to give `urlto` a special case that references the root of the wiki, + with a trailing slash ready to append stuff: perhaps `urlto('/')`, + with usage like this? + + do_something(baseurl => urlto('/', undef, local)`); + do_something_else(urlto('/').'style.css'); + IkiWiki::redirect(urlto('/', undef, 1));