current status
[[done]] again! :)
Actually, there are two places where the configured url is still hardcoded:
- When searching, all the links will use it. This is annoying to fix,
and we deem it not a problem.
- When ikiwiki dies with an error, the links on the error page will
use it. Too bad :)
semi-old
-
CGI pages, with the exception of edit pages, set <base> to
$config{url}
I had to revert using baseurl(undef) for that, because it needs
to be a full url.
Ideally, baseurl would return an absolute url derived from the url
being used to access the cgi, but that needs access to the CGI object,
which it does not currently have. Similarly, misctemplate
does not have access to the CGI object, so it cannot use it to
generate a better baseurl. Not sure yet what to do; may have to thread
a cgi parameter through all the calls to misctemplate. --[[Joey]]
Fixed, cgitemplate is used now. --[[Joey]]
-
Using do=goto to go to a comment or recentchanges item
will redirect to the $config{url} -based url, since the
permalinks are made to be absolute urls now.
Fixing this would seem to involve making meta force permalinks
to absolute urls when fulling out templates, while allowing them
to be left as partial urls internally, for use by goto. --[[Joey]]
This reversion has now been fixed. --[[Joey]]
old attempt
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
support 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 seemed to
work nicely (there might be bugs in some plugins, I didn't try all of them).
The branch at [[todo/use secure cookies for SSL logins]] goes well with
this one.
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.
Well, the docwiki doesn't have an url configured at all, so I assumed
it would need to fall back to current behavior in that case. I had
not thought about browsing wiki's html files though, good point.
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]]
That makes a great deal of sense, bravo for actually removing
parameters in the common case while maintaining backwards
compatability! --[[Joey]]
Done in my localurl branch; not tested in a whole-wiki way
yet, but I did add a regression test. I've used
urlto(x, undef) rather than urlto(x) so far, but I could
go back through the codebase using the short form if you'd
prefer. --[[smcv]]
It does highlight that it would be better to have a
absolute_urlto($link) (or maybe absolute(urlto($link)) )
rather than the 3 parameter form. --[[Joey]]
Possibly. I haven't added this.
-
IkiWiki::baseurl has a new second argument which works like the
third argument of urlto
I assume you have no objection to this --[[smcv]]
It's so little used that I don't really care if it's a bit ugly.
(But I assume changes to urlto will follow through here anyway.)
--[[Joey]]
I had to use it a bit more, as a replacement for $config{url}
when doing things like referencing stylesheets or redirecting to
the top of the wiki.
I ended up redoing this without the extra parameter. Previously,
baseurl(undef) was the absolute URL; now, baseurl(undef) is
the local path. I know you objected to me using baseurl() in
an earlier branch, because baseurl().$x looks confusingly
similar to baseurl($x) but has totally different semantics;
I've generally written it baseurl(undef) now, to be more
explicit. --[[smcv]]
-
IkiWiki::cgiurl uses $local_cgiurl if passed local_cgiurl => 1
Now changed to always use the $local_cgiurl . --[[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]]
Nod, although I don't know of a use case. --[[Joey]]
The use-case is that I can replace $config{cgiurl} with
IkiWiki::cgiurl() for things like the action attribute of
forms. --[[smcv]]
Fixed 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]]
Yes, I absolutely think it should default to local. (Note that
if absolute() were implemented as suggested above, it could also
be used with cgiurl if necessary.) --[[Joey]]
Done (minus absolute() ). --[[smcv]]
Potential future things:
-
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. For what it's worth, my branch has 6 uses in IkiWiki
core code (IkiWiki, CGI, Render and the pseudo-core part of editpage)
and 5 in plugins, since I used it for things like redirection back
to the top of the wiki --[[smcv]]
merged|done --[[Joey]] (But reopened, see above.)
Update: I had to revert part of 296e5cb2fd3690e998b3824d54d317933c595873,
since it broke openid logins. The openid object requires a complete,
not a relative cgiurl. I'm not sure if my changing that back to using
$config{cgiurl} will force users back to eg, the non-https version of a
site when logging in via openid.
Ok, changed it to use CGI->url to get the current absolute cgi url. --[[Joey]]
|