Item2083: Improve foswiki_redirect_cache solution

This bug item is tracking improvements to the fix in Item1766

I closed Item1766 in a 1.0.7 contect and created this one to track further improvements with a "Normal" priority for the 1.1

The background is to find a solution to forwarding the foswiki_redirect_cache on. The choice is between URL parameter or an extra level in the path. Both have pros and cons.

The result was that in 1.0.7 a configuration parameter was added with query parameter as default which is the way things have worked for years.

This item tracks finding a better solution.

-- KennethLavrsen - 16 Sep 2009

Tracking some lingering issues. My attempt at bringing several bugs together:

• Item2249: odd redirect error on login (closed no action/duplicate, continued here) - *shorturl*
• Item2288: Broken redirect from Login back to an Edit screen - origurl=//... Rewrite rules - waiting for reporter to confirm
• Item2597: login script redirect sometimes misses hostname part - origurl=//... - Rewrite rules
• Item1945: CSRF uses relative location for redirect which violates HTTP specs - *??*
• Item446: Make redirectto aware of anchors in links
• Item2602: Talks about Foswiki::Func::redirectCgiQuery which was deprecated in Development.RemoveRedirectCGIQueryHandler - not relevant
• Item8599: urlhost not recognised with url redirectcache to 'origurl=/' *shorturls*
• Item8937: redirectcache breaks TOC links on trunk - not relevant? redirect_cache saves and restores the action. Does not appear to be needed and dropped from the cache. (Updated: Actual fix was to bypass the cache when redirecting for the return from bin/login.
• Item8917: odd recurring login screen not relevant? Apache config problem

-- PaulHarvey - 21 Apr 2010

---

As I use short URLs, even more aggressively than the default, I also omit the WebHome topic, and the Home web, eg for me

• / is /Home/WebHome
• /WebNotify is /Home/WebNotify
• /Main/ is /Main/WebHome

I stubled on the bug myself. For this, here is what I needed to do: I used Crawford patch above, adapted to work in case the URL is short (i.e. has only one / in it), generating the full URL and using viewauth in this case, to avoid having the rewrite rules re-apply and mess things up if we used just view. viewauth works because short URLs are only used to authenticate on view anyways: attach, edit, etc do not use short URLs.

Note that I depend of a new configuration variable that should be declared in your lib/LocalSites.cfg: $Foswiki::cfg{HomeWebName} = 'Home'; (if "Home" is your "root" web - default sites would use $Foswiki::cfg{HomeWebName} = 'Main'; )

Here is my patch to 1.0.6, also attached as file login-shorturls-colasv1.patch

--- lib/Foswiki.pm      2009-09-08 07:43:14.000000000 +0200
+++ lib/Foswiki.pm.new  2009-09-08 07:43:05.000000000 +0200
@@ -899,7 +899,17 @@
             # Redirecting from a post to a get
             my $cache = $this->cacheQuery();
             if ($cache) {
-                $url .= $cache;
+               # Short URLs, (only one / in it), be careful
+               # See: http://foswiki.org/Tasks/Item1766
+               # Needs the config var $Foswiki::cfg{HomeWebName}
+               if ( $url =~ q!^[^/]*/[^/]*$! ) {
+                   if ( $url eq '/' ) {
+                       $url = $this->getScriptUrl(1, 'viewauth', $Foswiki::cfg{HomeWebName}, $Foswiki::cfg{HomeTopicName});
+                   } else {
+                       $url = $this->getScriptUrl(1, 'viewauth', $Foswiki::cfg{HomeWebName}, substr($url,1));
+                   }
+               }
+               $url .= $cache;
             }
         }
         else {

-- ColasNahaboo - 08 Sep 2009

I revisited this because it wasn't fixed on trunk, and saw what Colas had added above. Colas, as I understand it, this change is not required if you pass the redirect cache in a parameter, and not the URL, right? Also, the redirect $url is a bit weird; viewauth is only one of many scripts that might come through this code. Why does the rewriting only target viewauth?

-- CrawfordCurrie - 14 Sep 2009

FYI, I just noticed that with $Foswiki::cfg{UsePathForRedirectCache} = 0;, the problem that you cant login from the '/' url is still there, albeit in a different form. To quote AndrewJones:

19:17 < AndrewJones> gmc: found a problem with the new Foswiki. I tried to log in at http://foswiki.org/ and got the following error: Access check on Main failed. Action "redirect": unsafe redirect to

http://foswiki.org?foswiki_redirect_cache=7a75c47ee3f1d165a0e2ee43497d8b96

host does not match {DefaultUrlHost} , and is not in {PermittedRedirectHostUrls}"http://foswiki.org".

Possibly relevant settings:

$Foswiki::cfg{DefaultUrlHost} = 'http://foswiki.org/';
$Foswiki::cfg{ScriptUrlPath} = '/bin';
$Foswiki::cfg{ScriptUrlPaths}{view} = '';

Setting UsePathForRedirectCache to 1 fixed it.

-- KoenMartens - 15 Sep 2009

Regarded to Urgent, because this is clearly still a problem and needs some dedicated debug time before 1.0.7.

-- CrawfordCurrie - 18 Sep 2009

I have had the same problem reported by Andrew ("oops Access Denied" - unsafe redirect) and setting UsePathForRedirectCache to 1 works for me. Maybe another option could be append a slash in the end of the url (something like $url .= '/' unless $url =~ /\/$/;) just after getScriptUrl.

-- ItaloValcy - 24 Oct 2009

I think the current solution (setting UsePathForRedirectCache when using short URLs) works for most people. Am I wrong? Can someone verify that?

-- CrawfordCurrie - 17 Nov 2009

I had a brainstorm, and implemented a proper fix - you should be able to confirm an upload now, after a 'Back'. Trunk only. Further testing would be very welcome!

-- CrawfordCurrie - 19 Nov 2009

Added some notes at the top. I am having some redirect cache issues; not sure that this item is fully resolved. Will re-open if I can reproduce some issues reliably on a vanilla trunk.

-- PaulHarvey - 21 Apr 2010

I believe I've fixed the issue with %SCRIPTNAME% being incorrectly set to login following redirect. The session action does not need to be saved/restored because the script target of the redirect will correctly set the action.

-- GeorgeClark - 26 Apr 2010

CrawfordCurrie proposed some changes in FoswikiRedirectCache which resolves a loop issue created by changes to FSA. I'm committing them to this task.

-- GeorgeClark - 01 May 2010

Not sure how we can close this report; I think all the issues are addressed. Marking waiting for feedback.

-- CrawfordCurrie - 03 May 2010

I think Kenneth's original concerns are addressed now; well, we already closed this once, then I re-opened it.

Some of the tasks mentioned still need work, but they can continue there.

-- PaulHarvey - 04 May 2010

Yes if you believe the issues are resolved then we get put it waiting for release.

I created this report because the original problem was urgent and got a quick workaround implemented for 1.0.7. This report was to remind that we needed a fix that made the feature work as originally intended. And I assume this is where are now.

-- KennethLavrsen - 04 May 2010

Re-opened because good old Tasks web pointed up a problem. Later: fixed.

-- CrawfordCurrie - 05 May 2010