2008-02-14 21:40:22 +01:00
|
|
|
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.
|
|
|
|
|
2008-02-15 10:10:08 +01:00
|
|
|
-- Brian May
|
2008-02-14 21:46:24 +01:00
|
|
|
|
|
|
|
> 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]]
|
2008-02-15 10:10:08 +01:00
|
|
|
|
2010-08-30 20:41:59 +02:00
|
|
|
>> 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
|
2008-02-24 23:01:37 +01:00
|
|
|
|
|
|
|
>>> 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]]
|
|
|
|
|
2010-08-30 20:41:59 +02:00
|
|
|
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
|
2008-04-11 01:54:38 +02:00
|
|
|
|
|
|
|
> The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]
|
2008-10-02 21:12:57 +02:00
|
|
|
|
2010-08-30 20:41:59 +02:00
|
|
|
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]]
|
2010-08-05 02:38:44 +02:00
|
|
|
|
2008-10-02 21:12:57 +02:00
|
|
|
[[wishlist]]
|
2010-09-26 23:53:00 +02:00
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
[[!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)
|
2010-09-26 23:53:54 +02:00
|
|
|
|
|
|
|
--[[smcv]]
|
2010-09-27 05:01:01 +02:00
|
|
|
|
|
|
|
> 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?
|
2010-09-27 20:48:58 +02:00
|
|
|
|
|
|
|
>> 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.
|
|
|
|
>>
|
2010-09-27 21:36:05 +02:00
|
|
|
>>> 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]]
|
|
|
|
>>
|
2010-09-27 20:48:58 +02:00
|
|
|
>> 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]]
|
2010-09-27 21:36:05 +02:00
|
|
|
>>>
|
|
|
|
>>> Maybe, or I wonder if you could just use RewriteEngine for such selective
|
|
|
|
>>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]]
|
2010-09-27 20:48:58 +02:00
|
|
|
|
2010-09-27 05:01:01 +02:00
|
|
|
> 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.
|
2010-09-27 20:48:58 +02:00
|
|
|
|
|
|
|
>> That's a good point. --s
|
|
|
|
|
2010-09-27 05:01:01 +02:00
|
|
|
> 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.
|
2010-09-27 20:48:58 +02:00
|
|
|
|
|
|
|
>> 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
|
2010-09-29 02:28:14 +02:00
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
**warning: untested branch ** [[!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 at all (it's getting rather late in UK time)
|
|
|
|
and it will probably be rebased later, but I've referenced it here as a proof of
|
|
|
|
concept.
|
|
|
|
|
|
|
|
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. My branch adds config options which
|
|
|
|
could be set as follows for ikiwiki.info or any branchable.com site:
|
|
|
|
|
|
|
|
* local_url: /
|
|
|
|
* local_cgiurl: /ikiwiki.cgi
|
|
|
|
|
|
|
|
Most redirects, form actions, links etc. can safely use this form rather than
|
|
|
|
the fully-absolute URL. If not configured, these options default to the
|
|
|
|
corresponding absolute URL, which is would also be correct for unusual sites
|
|
|
|
where the CGI and the pages aren't on the same server.
|
|
|
|
|
|
|
|
(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...
|