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]]"]]
|
|
|
|
[[!tag patch]]
|
|
|
|
|
|
|
|
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?
|
|
|
|
>
|
|
|
|
> 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.
|
|
|
|
>
|
|
|
|
> 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.
|
|
|
|
>
|
|
|
|
> --[[Joey]]
|