doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn

   1 It looks like all links in websites are absolute paths, this has some limitations:
   2
   3 * If connecting to website via https://... all links will take you back to http://
   4 * Makes it harder to mirror website via HTML version, as all links have to be updated.
   5
   6 It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested.
   7
   8 -- Brian May
   9
  10 > Er, which absolute links are you talking about? If you view the source
  11 > to this page, you'll find links such as "../favicon.ico", "../style.css",
  12 > "../../", and "../". The only absolute links are to CGIs and the w3c DTD.
  13 > --[[Joey]]
  14
  15 >> The problem is within the CGI script. The links within the HTML page are all
  16 >> absolute, including links to the css file. Having a http links within a HTML
  17 >> page retrieved using https upset most browsers (I think). Also if I push cancel
  18 >> on the edit page in https, I end up at at http page. -- Brian May
  19
  20 >>> Ikiwiki does not hardcode http links anywhere. If you don't want
  21 >>> it to use such links, change your configuration to use https
  22 >>> consistently. --[[Joey]]
  23
  24 Errr... That is not a solution, that is a work around. ikiwiki does not hard
  25 code the absolute paths, but absolute paths are hard coded in the configuration
  26 file. If you want to serve your website so that the majority of users can see
  27 it as http, including in rss feeds (this allows proxy caches to cache the
  28 contents and has reduced load requirements), but editing is done via https for
  29 increased security, it is not possible. I have some ideas how this can be
  30 implemented (as ikiwiki has the absolute path to the CGI script and the
  31 absolute path to the destination, it should be possible to generate a relative
  32 path from one to the other), although some minor issues still need to be
  33 resolved. -- Brian May
  34
  35 I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are
  36 also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems
  37 surprising, as the change.tmpl file uses &lt;TMPL_VAR BASEURL&gt; which seems
  38 to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL
  39 set? -- Brian May
  40
  41 > The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]
  42
  43 So I'm facing this same issue. I have a wiki which needs to be accessed on
  44 three different URLs(!) and the hard coding of the URL from the setup file is
  45 becoming a problem for me. Is there anything I can do here? --[[Perry]]
  46
  47 > I remain puzzled by the problem that Brian is discussing. I don't see
  48 > why you can't just set the cgiurl and url to a https url, and serve
  49 > the site using both http and https.
  50 >
  51 > Just for example, <https://kitenet.net/> is an ikiwiki, and it is accessible
  52 > via https or http, and if you use https, links will remain on https (except
  53 > for links using the cgi, which I could fix by changing the cgiurl to https).
  54 >
  55 > I think it's possible ikiwiki used to have some
  56 > absolute urls that have been fixed since Brian filed the bug. --[[Joey]]
  57
  58 [[wishlist]]
  59
  60 ----
  61
  62 [[!toggle id="smcv-https" text="Some discussion of a rejected implementation, smcv/https."]]
  63 [[!toggleable id="smcv-https" text="""
  64
  65 [[!template id=gitbranch branch=smcv/https author="[[smcv]]"]]
  66
  67 For a while I've been using a configuration where each wiki has a HTTP and
  68 a HTTPS mirror, and updating one automatically updates the other, but
  69 that seems unnecessarily complicated. My `https` branch adds `https_url`
  70 and `https_cgiurl` config options which can be used to provide a HTTPS
  71 variant of an existing site; the CGI script automatically detects whether
  72 it was accessed over HTTPS and switches to the other one.
  73
  74 This required some refactoring, which might be worth merging even if
  75 you don't like my approach:
  76
  77 * change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if
  78   called with no parameters, and change all plugins to indirect through it
  79   (then I only need to change that one function for the HTTPS hack)
  80
  81 * `IkiWiki::baseurl` already has similar behaviour, so change nearly all
  82   references to the `$config{url}` to call `baseurl` (a couple of references
  83   specifically wanted the top-level public URL for Google or Blogspam rather
  84   than a URL for the user's browser, so I left those alone)
  85
  86 --[[smcv]]
  87
  88 > The justification for your patch seems to be wanting to use a different
  89 > domain, like secure.foo.com, for https? Can you really not just configure
  90 > both url and cgiurl to use `https://secure.foo.com/...` and rely on
  91 > relative links to keep users of `http://insecure.foo.com/` on http until
  92 > they need to use the cgi?
  93
  94 >> My problem with that is that uses of the CGI aren't all equal (and that
  95 >> the CA model is broken). You could put CGI uses in two classes:
  96 >>
  97 >> - websetup and other "serious" things (for the sites I'm running, which
  98 >>   aren't very wiki-like, editing pages is also in this class).
  99 >>   I'd like to be able to let privileged users log in over
 100 >>   https with httpauth (or possibly even a client certificate), and I don't
 101 >>   mind teaching these few people how to do the necessary contortions to
 102 >>   enable something like CACert.
 103 >>
 104 >> - Random users making limited use of the CGI: do=goto, do=404, and
 105 >>   commenting with an OpenID. I don't think it's realistic to expect
 106 >>   users to jump through all the CA hoops to get CACert installed for that,
 107 >>   which leaves their browsers being actively obstructive, unless I either
 108 >>   pay the CA tax (per subdomain) to get "real" certificates, or use plain
 109 >>   http.
 110 >>
 111 >> On a more wiki-like wiki, the second group would include normal page edits.
 112 >>
 113 >>> I see your use case. It still seems to me that for the more common
 114 >>> case where CA tax has been paid (getting a cert that is valid for
 115 >>> multiple subdomains should be doable?), having anything going through the
 116 >>> cgiurl upgrade to https would be ok. In that case, http is just an
 117 >>> optimisation for low-value, high-aggregate-bandwidth type uses, so a
 118 >>> little extra https on the side is not a big deal. --[[Joey]]
 119 >>
 120 >> Perhaps I'm doing this backwards, and instead of having the master
 121 >> `url`/`cgiurl` be the HTTP version and providing tweakables to override
 122 >> these with HTTPS, I should be overriding particular uses to plain HTTP...
 123 >>
 124 >> --[[smcv]]
 125 >>>
 126 >>> Maybe, or I wonder if you could just use RewriteEngine for such selective
 127 >>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]]
 128
 129 > I'm unconvinced.
 130 >
 131 > `Ikiwiki::baseurl()."foo"` just seems to be asking for trouble,
 132 > ie being accidentially written as `IkiWiki::baseurl("foo")`,
 133 > which will fail when foo is not a page, but some file.
 134
 135 >> That's a good point. --s
 136
 137 > I see multiple places (inline.pm, meta.pm, poll.pm, recentchanges.pm)
 138 > where it will now put the https url into a static page if the build
 139 > happens to be done by the cgi accessed via https, but not otherwise.
 140 > I would rather not have to audit for such problems going forward.
 141
 142 >> Yes, that's a problem with this approach (either way round). Perhaps
 143 >> making it easier to run two mostly-synched copies like I was previously
 144 >> doing is the only solution... --s
 145
 146 """]]
 147
 148 ----
 149
 150 [[!template id=gitbranch branch=smcv/ready/localurl author="[[smcv]]"]]
 151 [[!tag patch]]
 152
 153 OK, here's an alternative approach, closer in spirit to what was initially
 154 requested. I included a regression test for `urlto`, `baseurl` and `cgiurl`,
 155 now that they have slightly more complex behaviour.
 156
 157 The idea is that in the common case, the CGI and the pages will reside on the
 158 same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`,
 159 `/bugs/done`) to refer to each other. Most redirects, form actions, links etc.
 160 can safely use this form rather than the fully-absolute URL.
 161
 162 The initial version of the branch had config options `local_url` and
 163 `local_cgiurl`, but they're now automatically computed by checking
 164 whether `url` and `cgiurl` are on the same server with the the same URL
 165 scheme. In theory you could use things like `//static.example.com/wiki/`
 166 and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https
 167 while switching server, but I don't know how consistently browsers
 168 suppot that.
 169
 170 "local" here is short for "locally valid", because these URLs are neither
 171 fully relative nor fully absolute, and there doesn't seem to be a good name
 172 for them...
 173
 174 I've tested this on a demo website with the CGI enabled, and it seems to
 175 work nicely (there might be bugs in some plugins, I didn't try all of them).
 176 The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable
 177 `httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log
 178 in via that, links all end up in the HTTPS version.
 179
 180 New API added by this branch:
 181
 182 * `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}`
 183
 184   > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many,
 185   > and po overrides it), but I dislike overloading the third parameter
 186   > like that.
 187   >
 188   > There are fairly few calls to `urlto($foo, $bar)`, so why not
 189   > make that always return the semi-local url form, and leave the third
 190   > parameter for the cases that need a true fully-qualified url.
 191   > The new form for local urls will typically be only a little bit longer,
 192   > except in the unusual case where the cgiurl is elsewhere. --[[Joey]]
 193
 194   >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO
 195   >> they're for the most important things - wikilinks, img, map and
 196   >> other ordinary hyperlinks. Using `$local_url` would be fine for
 197   >> webserver-based use, but it does stop you browsing your wiki's
 198   >> HTML over `file:///` (unless you set that as the base URL, but
 199   >> then you can't move it around), and stops you moving simple
 200   >> outputs (like the docwiki!) around.
 201   >>
 202   >> I personally think breaking the docwiki is enough to block that.
 203   >>
 204   >> How about this?
 205   >>
 206   >> * `urlto($link, $page)` with `$page` defined: relative
 207   >> * `urlto($link, undef)`: local, starts with `/`
 208   >> * `urlto($link)`: also local, as a side-effect
 209   >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is
 210   >>   normally undef): absolute, starts with `http[s]://`
 211   >>
 212   >> --[[smcv]]
 213
 214 * `IkiWiki::baseurl` has a new second argument which works like the
 215   third argument of `urlto`
 216
 217   > I assume you have no objection to this --[[smcv]]
 218
 219 * `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
 220
 221   > Possibly changed to making this always be local unless `cgiurl => $x`
 222   > is given: see below --[[smcv]]
 223
 224 * `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters
 225   except `cgiurl` and/or `local_cgiurl`
 226
 227   > I assume you have no objection to this --[[smcv]]
 228
 229 Bugs:
 230
 231 * I don't think anything except `openid` calls `cgiurl` without also
 232   passing in `local_cgiurl => 1`, so perhaps that should be the default;
 233   `openid` uses the `cgiurl` named parameter anyway, so there doesn't even
 234   necessarily need to be a way to force absolute URLs? Any other module
 235   that really needs an absolute URL could use
 236   `cgiurl(cgiurl => $config{cgiurl}, ...)`,
 237   although that does look a bit strange
 238
 239   > I agree that makes sense. --[[Joey]]
 240
 241   >> I'm not completely sure whether you're agreeing with "perhaps do this"
 242   >> or "that looks too strange", so please disambiguate:
 243   >> would you accept a patch that makes `cgiurl` default to a local
 244   >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]]
 245
 246 * It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
 247   exported? Perhaps also `IkiWiki::baseurl`?
 248
 249   > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]]
 250
 251   >> Not really part of this branch, though, so wontfix (unless you ask me
 252   >> to do so). --[[smcv]]
 253
 254 * Or, to reduce use of the unexported `baseurl` function, it might make
 255   sense to give `urlto` a special case that references the root of the wiki,
 256   with a trailing slash ready to append stuff: perhaps `urlto('/')`,
 257   with usage like this?
 258
 259         do_something(baseurl => urlto('/', undef, local)`);
 260         do_something_else(urlto('/').'style.css');
 261         IkiWiki::redirect(urlto('/', undef, 1));
 262
 263   > AFACIS, `baseurl` is only called in 3 places so I don't think that's
 264   > needed. --[[Joey]]
 265
 266   >> OK, wontfix. --[[smcv]]