Merge branch 'joey' into revert

[ikiwiki.git] / doc / todo / want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn

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://
* Makes it harder to mirror website via HTML version, as all links have to be updated.

It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested.

-- Brian May

> Er, which absolute links are you talking about? If you view the source
> to this page, you'll find links such as "../favicon.ico", "../style.css",
> "../../", and "../". The only absolute links are to CGIs and the w3c DTD.
> --[[Joey]]

>> The problem is within the CGI script. The links within the HTML page are all
>> absolute, including links to the css file. Having a http links within a HTML
>> page retrieved using https upset most browsers (I think). Also if I push cancel
>> on the edit page in https, I end up at at http page. -- Brian May

>>> Ikiwiki does not hardcode http links anywhere. If you don't want
>>> it to use such links, change your configuration to use https
>>> consistently. --[[Joey]]

Errr... That is not a solution, that is a work around. ikiwiki does not hard
code the absolute paths, but absolute paths are hard coded in the configuration
file. If you want to serve your website so that the majority of users can see
it as http, including in rss feeds (this allows proxy caches to cache the
contents and has reduced load requirements), but editing is done via https for
increased security, it is not possible. I have some ideas how this can be
implemented (as ikiwiki has the absolute path to the CGI script and the
absolute path to the destination, it should be possible to generate a relative
path from one to the other), although some minor issues still need to be
resolved. -- Brian May

I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are
also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems
surprising, as the change.tmpl file uses &lt;TMPL_VAR BASEURL&gt; which seems
to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL
set? -- Brian May

> The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]

So I'm facing this same issue. I have a wiki which needs to be accessed on
three different URLs(!) and the hard coding of the URL from the setup file is
becoming a problem for me. Is there anything I can do here? --[[Perry]]

> I remain puzzled by the problem that Brian is discussing. I don't see
> why you can't just set the cgiurl and url to a https url, and serve
> the site using both http and https.
> 
> Just for example, <https://kitenet.net/> is an ikiwiki, and it is accessible
> via https or http, and if you use https, links will remain on https (except
> for links using the cgi, which I could fix by changing the cgiurl to https).
> 
> I think it's possible ikiwiki used to have some
> 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/localurl author="[[smcv]]"]]

OK, here's an alternative approach, closer in spirit to what was initially
requested. I haven't tested this on a full website with the CGI yet.

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...

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));