From: Joey Hess Date: Mon, 21 Mar 2011 17:47:12 +0000 (-0400) Subject: Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/commitdiff_plain/14b8abe60f02a9a31eb4b7ad489e6806637610f7?hp=e96ecf2f9317b0f7d547e86bcaf67b3aebecd8ea Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info --- diff --git a/doc/bugs/trouble_with_base_in_search.mdwn b/doc/bugs/trouble_with_base_in_search.mdwn new file mode 100644 index 000000000..4ca2b4bef --- /dev/null +++ b/doc/bugs/trouble_with_base_in_search.mdwn @@ -0,0 +1,53 @@ +For security reasons, one of the sites I'm in charge of uses a Reverse Proxy to grab the content from another machine behind our firewall. +Let's call the out-facing machine Alfred and the one behind the firewall Betty. + +For the static pages, everything is fine. However, when trying to use the search, all the links break. +This is because, when Alfred passes the search query on to Betty, the search result has a "base" tag which points to Betty, and all the links to the "found" pages are relative. +So we have + + + ... + path/to/found/page + +This breaks things for anyone on Alfred, because Betty is behind a firewall and they can't get there. + +What would be better is if it were possible to have a "base" which didn't reference the hostname, and for the "found" links not to be relative. +Something like this: + + + ... + path/to/found/page + +The workaround I've come up with is this. + +1. Set the "url" in the config to ' ' (a single space). It can't be empty because too many things complain if it is. +2. Patch the search plugin so that it saves an absolute URL rather than a relative one. + +Here's a patch: + + diff --git a/IkiWiki/Plugin/search.pm b/IkiWiki/Plugin/search.pm + index 3f0b7c9..26c4d46 100644 + --- a/IkiWiki/Plugin/search.pm + +++ b/IkiWiki/Plugin/search.pm + @@ -113,7 +113,7 @@ sub indexhtml (@) { + } + $sample=~s/\n/ /g; + + - my $url=urlto($params{destpage}, ""); + + my $url=urlto($params{destpage}, undef); + if (defined $pagestate{$params{page}}{meta}{permalink}) { + $url=$pagestate{$params{page}}{meta}{permalink} + } + +It works for me, but it has the odd side-effect of prefixing links with a space. Fortunately that doesn't seem to break browsers. +And I'm sure someone else could come up with something better and more general. + +--[[KathrynAndersen]] + +> The `` is required to be genuinely absolute (HTML 4.01 §12.4). +> Have you tried setting `url` to the public-facing URL, i.e. with `alfred` +> as the hostname? That seems like the cleanest solution to me; if you're +> one of the few behind the firewall and you access the site via `betty` +> directly, my HTTP vs. HTTPS cleanup in recent versions should mean that +> you rarely get redirected to `alfred`, because most URLs are either +> relative or "local" (start with '/'). --[[smcv]] diff --git a/doc/plugins/aggregate/discussion.mdwn b/doc/plugins/aggregate/discussion.mdwn index a3336ee08..80788fb1b 100644 --- a/doc/plugins/aggregate/discussion.mdwn +++ b/doc/plugins/aggregate/discussion.mdwn @@ -121,3 +121,15 @@ the user agent to be programmatically manipulated? --[[schmonz]] >> Pong.. I'd be happier with a more 100% solution that let cookies be used >> w/o needing to write a custom plugin to do it. --[[Joey]] + +>>> According to LWP::UserAgent, for the common case, a complete +>>> and valid configuration for `$config{cookies}` would be `{ file => +>>> "$ENV{HOME}/.cookies.txt" }`. In the more common case of not needing +>>> to prime one's cookies, `cookie_jar` can be `undef` (that's the +>>> default). In my less common case, the cookies are generated by +>>> visiting a couple magic URLs, which would be trivial to turn into +>>> config options, except that these particular URLs rely on SPNEGO +>>> and so LWP::Authen::Negotiate has to be loaded. So I think adding +>>> `$config{cookies}` (and using it in the aggregate plugin) should +>>> be safe, might help people in typical cases, and won't prevent +>>> further enhancements for less typical cases. --[[schmonz]]