Item2083: Improve foswiki_redirect_cache solution

Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Reported By: KennethLavrsen
Waiting For:
Last Change By: KennethLavrsen
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/      2009-09-08 07:43:14.000000000 +0200
+++ lib/  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:
+               # 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 and got the following error: Access check on Main failed. Action "redirect": unsafe redirect to
host does not match {DefaultUrlHost} , and is not in {PermittedRedirectHostUrls}"".

Possibly relevant settings:

$Foswiki::cfg{DefaultUrlHost} = '';
$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

ItemTemplate edit

Summary Improve foswiki_redirect_cache solution
ReportedBy KennethLavrsen
Codebase trunk
SVN Range Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272
AppliesTo Engine
Priority Urgent
CurrentState Closed
Checkins distro:07008cddfe9a distro:61484f536e07 distro:4dd2e1863125 distro:71a57ec135d6 distro:70da69a6ecde
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r23 - 04 Oct 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy