X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/e789cb9c84ba22570de18ff530c428c6fbe56e77..b216f42e8ea6953456381e041d248b5cf958d8ab:/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 112112284..dfe41e138 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 @@ -1,3 +1,30 @@ +## current status + +99% of the way there, but: + +* CGI pages, with the exception of edit pages, set `` to + `$config{url}` + + I had to revert using `baseurl(undef)` for that, because it needs + to be a full url. + + Ideally, baseurl would return an absolute url derived from the url + being used to access the cgi, but that needs access to the CGI object, + which it does not currently have. Similarly, `misctemplate` + does not have access to the CGI object, so it cannot use it to + generate a better baseurl. Not sure yet what to do; may have to thread + a cgi parameter through all the calls to misctemplate. --[[Joey]] + +* Using `do=goto` to go to a comment or recentchanges item + will redirect to the `$config{url}`-based url, since the + permalinks are made to be absolute urls now. + + Fixing this would seem to involve making meta force permalinks + to absolute urls when fulling out templates, while allowing them + to be left as partial urls internally, for use by goto. --[[Joey]] + +## old attempt + It looks like all links in websites are absolute paths, this has some limitations: * If connecting to website via https://... all links will take you back to http:// @@ -59,8 +86,10 @@ becoming a problem for me. Is there anything I can do here? --[[Perry]] ---- +[[!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]]"]] -[[!tag patch]] 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 @@ -82,3 +111,250 @@ you don't like my approach: 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 +support 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 seemed to +work nicely (there might be bugs in some plugins, I didn't try all of them). +The branch at [[todo/use secure cookies for SSL logins]] goes well with +this one. + +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}` + + > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many, + > and po overrides it), but I dislike overloading the third parameter + > like that. + > + > There are fairly few calls to `urlto($foo, $bar)`, so why not + > make that always return the semi-local url form, and leave the third + > parameter for the cases that need a true fully-qualified url. + > The new form for local urls will typically be only a little bit longer, + > except in the unusual case where the cgiurl is elsewhere. --[[Joey]] + + >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO + >> they're for the most important things - wikilinks, img, map and + >> other ordinary hyperlinks. Using `$local_url` would be fine for + >> webserver-based use, but it does stop you browsing your wiki's + >> HTML over `file:///` (unless you set that as the base URL, but + >> then you can't move it around), and stops you moving simple + >> outputs (like the docwiki!) around. + >> + >> I personally think breaking the docwiki is enough to block that. + >> + >>> Well, the docwiki doesn't have an url configured at all, so I assumed + >>> it would need to fall back to current behavior in that case. I had + >>> not thought about browsing wiki's html files though, good point. + >> + >> How about this? + >> + >> * `urlto($link, $page)` with `$page` defined: relative + >> * `urlto($link, undef)`: local, starts with `/` + >> * `urlto($link)`: also local, as a side-effect + >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is + >> normally undef): absolute, starts with `http[s]://` + >> + >> --[[smcv]] + >> + >>> That makes a great deal of sense, bravo for actually removing + >>> parameters in the common case while maintaining backwards + >>> compatability! --[[Joey]] + >>> + >>>> Done in my `localurl` branch; not tested in a whole-wiki way + >>>> yet, but I did add a regression test. I've used + >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could + >>>> go back through the codebase using the short form if you'd + >>>> prefer. --[[smcv]] + >>> + >>> It does highlight that it would be better to have a + >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` ) + >>> rather than the 3 parameter form. --[[Joey]] + >>> + >>> Possibly. I haven't added this. + +* `IkiWiki::baseurl` has a new second argument which works like the + third argument of `urlto` + + > I assume you have no objection to this --[[smcv]] + + >> It's so little used that I don't really care if it's a bit ugly. + >> (But I assume changes to `urlto` will follow through here anyway.) + >> --[[Joey]] + + >>> I had to use it a bit more, as a replacement for `$config{url}` + >>> when doing things like referencing stylesheets or redirecting to + >>> the top of the wiki. + >>> + >>> I ended up redoing this without the extra parameter. Previously, + >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is + >>> the local path. I know you objected to me using `baseurl()` in + >>> an earlier branch, because `baseurl().$x` looks confusingly + >>> similar to `baseurl($x)` but has totally different semantics; + >>> I've generally written it `baseurl(undef)` now, to be more + >>> explicit. --[[smcv]] + +* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1` + + > Now changed to always use the `$local_cgiurl`. --[[smcv]] + +* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters + except `cgiurl` and/or `local_cgiurl` + + > I assume you have no objection to this --[[smcv]] + > + >> Nod, although I don't know of a use case. --[[Joey]] + + >>> The use-case is that I can replace `$config{cgiurl}` with + >>> `IkiWiki::cgiurl()` for things like the action attribute of + >>> forms. --[[smcv]] + +Fixed 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 + + > I agree that makes sense. --[[Joey]] + + >> I'm not completely sure whether you're agreeing with "perhaps do this" + >> or "that looks too strange", so please disambiguate: + >> would you accept a patch that makes `cgiurl` default to a local + >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]] + + >>> Yes, I absolutely think it should default to local. (Note that + >>> if `absolute()` were implemented as suggested above, it could also + >>> be used with cgiurl if necessary.) --[[Joey]] + + >>>> Done (minus `absolute()`). --[[smcv]] + +Potential future things: + +* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being + exported? Perhaps also `IkiWiki::baseurl`? + + > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]] + + >> Not really part of this branch, though, so wontfix (unless you ask me + >> to do so). --[[smcv]] + +* 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)); + + > AFACIS, `baseurl` is only called in 3 places so I don't think that's + > needed. --[[Joey]] + + >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki + >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage) + >> and 5 in plugins, since I used it for things like redirection back + >> to the top of the wiki --[[smcv]] + +merged|done --[[Joey]] (But reopened, see above.) + +---- + +Update: I had to revert part of 296e5cb2fd3690e998b3824d54d317933c595873, +since it broke openid logins. The openid object requires a complete, +not a relative cgiurl. I'm not sure if my changing that back to using +`$config{cgiurl}` will force users back to eg, the non-https version of a +site when logging in via openid. + +> Ok, changed it to use `CGI->url` to get the current absolute cgi url. --[[Joey]]