267 lines
12 KiB
Markdown
267 lines
12 KiB
Markdown
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 <TMPL_VAR BASEURL> 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/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}`
|
|
|
|
> 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.
|
|
>>
|
|
>> 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]]
|
|
|
|
* `IkiWiki::baseurl` has a new second argument which works like the
|
|
third argument of `urlto`
|
|
|
|
> I assume you have no objection to this --[[smcv]]
|
|
|
|
* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
|
|
|
|
> Possibly changed to making this always be local unless `cgiurl => $x`
|
|
> is given: see below --[[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]]
|
|
|
|
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]]
|
|
|
|
* 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. --[[smcv]]
|