From efd9207e432ab8aa21fac8b8a4827624b2af7e3c Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawlcaGfdn9Kye1Gc8aGb67PDVQW4mKbQD7E" Date: Sun, 20 Mar 2011 20:19:06 +0000 Subject: [PATCH 1/4] response --- doc/plugins/aggregate/discussion.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) 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]] From 67ddc34fbcb22c4cd7174c35c8695a21de82eeef Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Mon, 21 Mar 2011 03:08:39 +0000 Subject: [PATCH 2/4] problem with reverse proxy and searching --- doc/bugs/trouble_with_base_in_search.mdwn | 43 +++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 doc/bugs/trouble_with_base_in_search.mdwn 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..16e4e7468 --- /dev/null +++ b/doc/bugs/trouble_with_base_in_search.mdwn @@ -0,0 +1,43 @@ +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. From a39a6911533afe79d1118ccd71ac84693f7501ff Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Mon, 21 Mar 2011 03:09:26 +0000 Subject: [PATCH 3/4] oops, it was me --- doc/bugs/trouble_with_base_in_search.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/bugs/trouble_with_base_in_search.mdwn b/doc/bugs/trouble_with_base_in_search.mdwn index 16e4e7468..24d411ae5 100644 --- a/doc/bugs/trouble_with_base_in_search.mdwn +++ b/doc/bugs/trouble_with_base_in_search.mdwn @@ -41,3 +41,5 @@ Here's a patch: 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]] From 7be18bf29a26a40a9c401fb4f5ce8c2ef3e33ffb Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Mon, 21 Mar 2011 14:31:33 +0000 Subject: [PATCH 4/4] base href has to be (fully) absolute --- doc/bugs/trouble_with_base_in_search.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/doc/bugs/trouble_with_base_in_search.mdwn b/doc/bugs/trouble_with_base_in_search.mdwn index 24d411ae5..4ca2b4bef 100644 --- a/doc/bugs/trouble_with_base_in_search.mdwn +++ b/doc/bugs/trouble_with_base_in_search.mdwn @@ -43,3 +43,11 @@ It works for me, but it has the odd side-effect of prefixing links with a space. 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]]