Welcome to 2019
[ikiwiki.git] / doc / todo / want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
1 ## current status
2
3 [[done]] again! :)
4
5 Actually, there are two places where the configured url is still hardcoded:
6
7 1. When searching, all the links will use it. This is annoying to fix,
8    and we deem it not a problem.
9 2. When ikiwiki dies with an error, the links on the error page will
10    use it. Too bad :)
11
12 ------
13
14 ## semi-old
15
16
17 * CGI pages, with the exception of edit pages, set `<base>` to
18   `$config{url}`
19
20   I had to revert using `baseurl(undef)` for that, because it needs
21   to be a full url.
22
23   Ideally, baseurl would return an absolute url derived from the url
24   being used to access the cgi, but that needs access to the CGI object,
25   which it does not currently have. Similarly, `misctemplate`
26   does not have access to the CGI object, so it cannot use it to
27   generate a better baseurl. Not sure yet what to do; may have to thread
28   a cgi parameter through all the calls to misctemplate. --[[Joey]]
29
30   > Fixed, cgitemplate is used now. --[[Joey]] 
31
32 * Using `do=goto` to go to a comment or recentchanges item
33   will redirect to the `$config{url}`-based url, since the
34   permalinks are made to be absolute urls now.
35
36   Fixing this would seem to involve making meta force permalinks
37   to absolute urls when fulling out templates, while allowing them
38   to be left as partial urls internally, for use by goto. --[[Joey]]
39
40   > This reversion has now been fixed. --[[Joey]]
41
42 ## old attempt
43
44 It looks like all links in websites are absolute paths, this has some limitations:
45
46 * If connecting to website via https://... all links will take you back to http://
47 * Makes it harder to mirror website via HTML version, as all links have to be updated.
48
49 It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested.
50
51 -- Brian May
52
53 > Er, which absolute links are you talking about? If you view the source
54 > to this page, you'll find links such as "../favicon.ico", "../style.css",
55 > "../../", and "../". The only absolute links are to CGIs and the w3c DTD.
56 > --[[Joey]]
57
58 >> The problem is within the CGI script. The links within the HTML page are all
59 >> absolute, including links to the css file. Having a http links within a HTML
60 >> page retrieved using https upset most browsers (I think). Also if I push cancel
61 >> on the edit page in https, I end up at at http page. -- Brian May
62
63 >>> Ikiwiki does not hardcode http links anywhere. If you don't want
64 >>> it to use such links, change your configuration to use https
65 >>> consistently. --[[Joey]]
66
67 Errr... That is not a solution, that is a work around. ikiwiki does not hard
68 code the absolute paths, but absolute paths are hard coded in the configuration
69 file. If you want to serve your website so that the majority of users can see
70 it as http, including in rss feeds (this allows proxy caches to cache the
71 contents and has reduced load requirements), but editing is done via https for
72 increased security, it is not possible. I have some ideas how this can be
73 implemented (as ikiwiki has the absolute path to the CGI script and the
74 absolute path to the destination, it should be possible to generate a relative
75 path from one to the other), although some minor issues still need to be
76 resolved. -- Brian May
77
78 I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are
79 also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems
80 surprising, as the change.tmpl file uses &lt;TMPL_VAR BASEURL&gt; which seems
81 to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL
82 set? -- Brian May
83
84 > The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]
85
86 So I'm facing this same issue. I have a wiki which needs to be accessed on
87 three different URLs(!) and the hard coding of the URL from the setup file is
88 becoming a problem for me. Is there anything I can do here? --[[Perry]]
89
90 > I remain puzzled by the problem that Brian is discussing. I don't see
91 > why you can't just set the cgiurl and url to a https url, and serve
92 > the site using both http and https.
93
94 > Just for example, <https://kitenet.net/> is an ikiwiki, and it is accessible
95 > via https or http, and if you use https, links will remain on https (except
96 > for links using the cgi, which I could fix by changing the cgiurl to https).
97
98 > I think it's possible ikiwiki used to have some
99 > absolute urls that have been fixed since Brian filed the bug. --[[Joey]]  
100
101 [[wishlist]]
102
103 ----
104
105 [[!toggle id="smcv-https" text="Some discussion of a rejected implementation, smcv/https."]]
106 [[!toggleable id="smcv-https" text="""
107
108 [[!template id=gitbranch branch=smcv/https author="[[smcv]]"]]
109
110 For a while I've been using a configuration where each wiki has a HTTP and
111 a HTTPS mirror, and updating one automatically updates the other, but
112 that seems unnecessarily complicated. My `https` branch adds `https_url`
113 and `https_cgiurl` config options which can be used to provide a HTTPS
114 variant of an existing site; the CGI script automatically detects whether
115 it was accessed over HTTPS and switches to the other one.
116
117 This required some refactoring, which might be worth merging even if
118 you don't like my approach:
119
120 * change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if
121   called with no parameters, and change all plugins to indirect through it
122   (then I only need to change that one function for the HTTPS hack)
123
124 * `IkiWiki::baseurl` already has similar behaviour, so change nearly all
125   references to the `$config{url}` to call `baseurl` (a couple of references
126   specifically wanted the top-level public URL for Google or Blogspam rather
127   than a URL for the user's browser, so I left those alone)
128
129 --[[smcv]]
130
131 > The justification for your patch seems to be wanting to use a different
132 > domain, like secure.foo.com, for https? Can you really not just configure
133 > both url and cgiurl to use `https://secure.foo.com/...` and rely on
134 > relative links to keep users of `http://insecure.foo.com/` on http until
135 > they need to use the cgi? 
136
137 >> My problem with that is that uses of the CGI aren't all equal (and that
138 >> the CA model is broken). You could put CGI uses in two classes:
139 >>
140 >> - websetup and other "serious" things (for the sites I'm running, which
141 >>   aren't very wiki-like, editing pages is also in this class).
142 >>   I'd like to be able to let privileged users log in over
143 >>   https with httpauth (or possibly even a client certificate), and I don't
144 >>   mind teaching these few people how to do the necessary contortions to
145 >>   enable something like CACert.
146 >>
147 >> - Random users making limited use of the CGI: do=goto, do=404, and
148 >>   commenting with an OpenID. I don't think it's realistic to expect
149 >>   users to jump through all the CA hoops to get CACert installed for that,
150 >>   which leaves their browsers being actively obstructive, unless I either
151 >>   pay the CA tax (per subdomain) to get "real" certificates, or use plain
152 >>   http.
153 >>
154 >> On a more wiki-like wiki, the second group would include normal page edits.
155 >>
156 >>> I see your use case. It still seems to me that for the more common
157 >>> case where CA tax has been paid (getting a cert that is valid for
158 >>> multiple subdomains should be doable?), having anything going through the
159 >>> cgiurl upgrade to https would be ok. In that case, http is just an
160 >>> optimisation for low-value, high-aggregate-bandwidth type uses, so a
161 >>> little extra https on the side is not a big deal. --[[Joey]]
162 >>
163 >> Perhaps I'm doing this backwards, and instead of having the master
164 >> `url`/`cgiurl` be the HTTP version and providing tweakables to override
165 >> these with HTTPS, I should be overriding particular uses to plain HTTP...
166 >>
167 >> --[[smcv]]
168 >>> 
169 >>> Maybe, or I wonder if you could just use RewriteEngine for such selective
170 >>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]]
171
172 > I'm unconvinced.
173
174 > `Ikiwiki::baseurl()."foo"` just seems to be asking for trouble,
175 > ie being accidentially written as `IkiWiki::baseurl("foo")`,
176 > which will fail when foo is not a page, but some file.
177
178 >> That's a good point. --s
179
180 > I see multiple places (inline.pm, meta.pm, poll.pm, recentchanges.pm)
181 > where it will now put the https url into a static page if the build
182 > happens to be done by the cgi accessed via https, but not otherwise.
183 > I would rather not have to audit for such problems going forward.
184
185 >> Yes, that's a problem with this approach (either way round). Perhaps
186 >> making it easier to run two mostly-synched copies like I was previously
187 >> doing is the only solution... --s
188
189 """]]
190
191 ----
192
193 [[!template id=gitbranch branch=smcv/ready/localurl author="[[smcv]]"]]
194 [[!tag patch]]
195
196 OK, here's an alternative approach, closer in spirit to what was initially
197 requested. I included a regression test for `urlto`, `baseurl` and `cgiurl`,
198 now that they have slightly more complex behaviour.
199
200 The idea is that in the common case, the CGI and the pages will reside on the
201 same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`,
202 `/bugs/done`) to refer to each other. Most redirects, form actions, links etc.
203 can safely use this form rather than the fully-absolute URL.
204
205 The initial version of the branch had config options `local_url` and
206 `local_cgiurl`, but they're now automatically computed by checking
207 whether `url` and `cgiurl` are on the same server with the the same URL
208 scheme. In theory you could use things like `//static.example.com/wiki/`
209 and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https
210 while switching server, but I don't know how consistently browsers
211 support that.
212
213 "local" here is short for "locally valid", because these URLs are neither
214 fully relative nor fully absolute, and there doesn't seem to be a good name
215 for them...
216
217 I've tested this on a demo website with the CGI enabled, and it seemed to
218 work nicely (there might be bugs in some plugins, I didn't try all of them).
219 The branch at [[todo/use secure cookies for SSL logins]] goes well with
220 this one.
221
222 The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable
223 `httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log
224 in via that, links all end up in the HTTPS version.
225
226 New API added by this branch:
227
228 * `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}`
229
230   > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many,
231   > and po overrides it), but I dislike overloading the third parameter
232   > like that.
233   > 
234   > There are fairly few calls to `urlto($foo, $bar)`, so why not
235   > make that always return the semi-local url form, and leave the third
236   > parameter for the cases that need a true fully-qualified url.
237   > The new form for local urls will typically be only a little bit longer,
238   > except in the unusual case where the cgiurl is elsewhere. --[[Joey]]
239
240   >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO
241   >> they're for the most important things - wikilinks, img, map and
242   >> other ordinary hyperlinks. Using `$local_url` would be fine for
243   >> webserver-based use, but it does stop you browsing your wiki's
244   >> HTML over `file:///` (unless you set that as the base URL, but
245   >> then you can't move it around), and stops you moving simple
246   >> outputs (like the docwiki!) around.
247   >>
248   >> I personally think breaking the docwiki is enough to block that.
249   >>
250   >>> Well, the docwiki doesn't have an url configured at all, so I assumed
251   >>> it would need to fall back to current behavior in that case. I had
252   >>> not thought about browsing wiki's html files though, good point.
253   >>
254   >> How about this?
255   >>
256   >> * `urlto($link, $page)` with `$page` defined: relative
257   >> * `urlto($link, undef)`: local, starts with `/`
258   >> * `urlto($link)`: also local, as a side-effect
259   >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is
260   >>   normally undef): absolute, starts with `http[s]://`
261   >>
262   >> --[[smcv]]
263   >> 
264   >>> That makes a great deal of sense, bravo for actually removing
265   >>> parameters in the common case while maintaining backwards
266   >>> compatability! --[[Joey]]
267   >>>
268   >>>> Done in my `localurl` branch; not tested in a whole-wiki way
269   >>>> yet, but I did add a regression test. I've used
270   >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could
271   >>>> go back through the codebase using the short form if you'd
272   >>>> prefer. --[[smcv]]
273   >>> 
274   >>> It does highlight that it would be better to have a
275   >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` )
276   >>> rather than the 3 parameter form. --[[Joey]]
277   >>>
278   >>> Possibly. I haven't added this.
279
280 * `IkiWiki::baseurl` has a new second argument which works like the
281   third argument of `urlto`
282
283   > I assume you have no objection to this --[[smcv]]
284
285   >> It's so little used that I don't really care if it's a bit ugly.
286   >> (But I assume changes to `urlto` will follow through here anyway.)
287   >> --[[Joey]] 
288
289   >>> I had to use it a bit more, as a replacement for `$config{url}`
290   >>> when doing things like referencing stylesheets or redirecting to
291   >>> the top of the wiki.
292   >>>
293   >>> I ended up redoing this without the extra parameter. Previously,
294   >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is
295   >>> the local path. I know you objected to me using `baseurl()` in
296   >>> an earlier branch, because `baseurl().$x` looks confusingly
297   >>> similar to `baseurl($x)` but has totally different semantics;
298   >>> I've generally written it `baseurl(undef)` now, to be more
299   >>> explicit. --[[smcv]]
300
301 * `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
302
303   > Now changed to always use the `$local_cgiurl`. --[[smcv]]
304
305 * `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters
306   except `cgiurl` and/or `local_cgiurl`
307
308   > I assume you have no objection to this --[[smcv]]
309   > 
310   >> Nod, although I don't know of a use case. --[[Joey]]
311
312   >>> The use-case is that I can replace `$config{cgiurl}` with
313   >>> `IkiWiki::cgiurl()` for things like the action attribute of
314   >>> forms. --[[smcv]]
315
316 Fixed bugs:
317
318 * I don't think anything except `openid` calls `cgiurl` without also
319   passing in `local_cgiurl => 1`, so perhaps that should be the default;
320   `openid` uses the `cgiurl` named parameter anyway, so there doesn't even
321   necessarily need to be a way to force absolute URLs? Any other module
322   that really needs an absolute URL could use
323   `cgiurl(cgiurl => $config{cgiurl}, ...)`,
324   although that does look a bit strange
325
326   > I agree that makes sense. --[[Joey]]
327
328   >> I'm not completely sure whether you're agreeing with "perhaps do this"
329   >> or "that looks too strange", so please disambiguate:
330   >> would you accept a patch that makes `cgiurl` default to a local
331   >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]]
332
333   >>> Yes, I absolutely think it should default to local. (Note that
334   >>> if `absolute()` were implemented as suggested above, it could also
335   >>> be used with cgiurl if necessary.) --[[Joey]]
336
337   >>>> Done (minus `absolute()`). --[[smcv]]
338
339 Potential future things:
340
341 * It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
342   exported? Perhaps also `IkiWiki::baseurl`?
343
344   > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]]
345
346   >> Not really part of this branch, though, so wontfix (unless you ask me
347   >> to do so). --[[smcv]]
348
349 * Or, to reduce use of the unexported `baseurl` function, it might make
350   sense to give `urlto` a special case that references the root of the wiki,
351   with a trailing slash ready to append stuff: perhaps `urlto('/')`,
352   with usage like this?
353
354         do_something(baseurl => urlto('/', undef, local)`);
355         do_something_else(urlto('/').'style.css');
356         IkiWiki::redirect(urlto('/', undef, 1));
357
358   > AFACIS, `baseurl` is only called in 3 places so I don't think that's
359   > needed. --[[Joey]] 
360
361   >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki
362   >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage)
363   >> and 5 in plugins, since I used it for things like redirection back
364   >> to the top of the wiki --[[smcv]]
365
366 merged|done --[[Joey]] (But reopened, see above.)
367
368 ----
369
370 Update: I had to revert part of 296e5cb2fd3690e998b3824d54d317933c595873,
371 since it broke openid logins. The openid object requires a complete,
372 not a relative cgiurl. I'm not sure if my changing that back to using
373 `$config{cgiurl}` will force users back to eg, the non-https version of a
374 site when logging in via openid.
375
376 > Ok, changed it to use `CGI->url` to get the current absolute cgi url. --[[Joey]]