Item1766: Redirecting to http://foswiki_redirect_cache... on first login of a browser session

I upgraded our test-in-progress Foswiki installation to 1.0.6, and now the first attempt at logging in results in a redirect to "http://foswiki_redirect_cache/_hex-digits_" instead of the original source document.

If I hit browser-back from the resulting browser error page, then cancel at the login page, I return to the source page and find that I am logged in despite the redirect flaw.

If I log out from that session but do not close the browser tab, I can log in normally after that first time. Closing the tab, or the browser, results in the error again. I expect that it would happen again in the same tab too if I waited through some timeout period.

We are using NatSkin/NatSkinPlugin, LdapContrib/LdapPluginNg against Active Directory, TemplateLogin with LdapUserMapping.

-- DonWennick - 22 Jun 2009

Additional: Same behavior with pattern skin, and any edit save attempt results in a Confirmation dialog, which then discards the edit when I click OK, although the wording seems to say the save will be accepted with OK.

-- DonWennick - 22 Jun 2009

Seems it is either

• A special server configuration that the new 1.0.6 code is not compatible with. Crawford did a change to the way the redirect is done in the URL.
• Or it is LdapContrib/LdapPluginNg/LdapUserMapping that is not compatible with the change.

I do not have an Ldap server I can test against. I have tested the login with TemplateLogin and standard TopicUserMapping and standard htpasswd. And it redirects correctly to the authentication and back to the topic you came from when authenticated. Even after two failed attempts and the 3rd with correct username/password.

Can you share with us your apache configuration - especially if you use rewrite rules?

-- KennethLavrsen - 22 Jun 2009

Attached my site config file, it was generated by the foswiki.org generator and I don't recall having manually edited anything further.

-- DonWennick - 22 Jun 2009

"the first attempt at logging in" - how did you try to log in? By clicking the "Log in" in the menu bar? By trying to edit a protected page? Some other way?

-- CrawfordCurrie - 23 Jun 2009

Current NatSkin does not work on 1.0.6. The next NatSkin version will skip 3.0 and go for 4.0 right away. That's why you get a confirmation dialog on every save using NatSkin...

Wrt LdapContrib...will test as soon as I come back from travelling .... I need a running env during that time, so I won't svn up and get the latest changes incl the new foswiki_redirect_cache schema.

-- MichaelDaum - 23 Jun 2009

CrawfordCurrie - logging in by clicking on "Log In".

MichaelDaum - thank you for the information. I reverted to my 1.0.5 backup to proceed with our in house testing, but retained the 1.0.6 installation so I can switch back & forth easily.

-- DonWennick - 23 Jun 2009

For information.

I think it is wrong to say that NatSkin does not work on 1.0.6. There are many good bug fixes in 1.0.6 that makes it interesting for users to upgrade anyway.

But the problem is the CSRF protection feature in 1.0.6 and until NatSkin is updated my guess is that disabling the CSRF protection will make NatSkin work fine.

In configure simply set {Validation}{Method} to 'none'

The LdapContrib redirect problem may be caused by the change in 1.0.6 to the foswiki_redirect_cache schema and that cannot be disabled. So for this bug report the LdapContrib will probably need a small fix.

But I find it sad if NatSkin gets a bad reputation as not working on 1.0.6. I am pretty sure the {Validation}{Method} to 'none' will do the trick. You will not have the CSRF protection feature but you will get all the other good bug fixes and once NatSkin is upgraded you can easily re-enable the CSRF protection.

-- KennethLavrsen - 23 Jun 2009

Whatever the fix to LdapContrib is: it must be backwards compatible. Too bad that we get into this trouble at all.

-- MichaelDaum - 23 Jun 2009

I ran into the same problem with a fresh 1.0.6. ; No LDAP, no NatSkin/ NatSkinPlugin !

Similar config from the ApacheConfigGenerator with short URLs and:

# short urls

Alias / "/var/www/foswiki/bin/view/"

First login: http://MySubdomain.MyDomain.de/bin/login/Main/WebHome?origurl=/

--> http://foswiki_redirect_cache/0497394c798999f800dbe6416f16097f

Second login: http://MySubdomain.MyDomain.de/bin/login/Main/WebHome?origurl=/Main/WebHome

--> http://MySubdomain.MyDomain.de/Main/WebHome/foswiki_redirect_cache/fee919aae5cad8d6c552c04fbc20c57e

I put view in {AuthScripts}, but it's the same without that and just using the "Log In" in the WebBar. When Strikeone (none) is disabled then everything is fine. I attached the (commented) rewrite logs with and without Strikeone. Still checking if its just my server config... If I can help helping me by providing additional info, just give a word.

-- IngoBlickling - 23 Jun 2009

I set up a new Ubunty Hardy Server VM and installed only Foswiki 1.0.6 and LdapContib. I generated a config from ApacheConfigGenerator using only "/" for the URL path, and short urls disabled to prevent rewriting issues.

I have no idea why this would be, but the generated line:

Alias / "/var/www/foswiki/bin/view"

in the Apache config causes the invalid redirected url. I changed that to:

RedirectMatch ^/$ http://server/bin/view

and authentication works normally. I put the same change in my original, upgraded server and login works fine now, but the save confirmations continue. Setting CSRF to "none" results in a confirmation request followed by redirect looping, using "strikeone" or "embedded" both ask for confirmation and then save OK - all of that is with NatSkin.

-- DonWennick - 23 Jun 2009

Like IngoBickling, I'm encountering this problem on a vanilla Foswiki 1.0.6 with an Apache configuration essentially as provided by the generator. Is there any information I can provide to help solve this problem? Thanks.

-- BruceNourish

Crawford. Seems the redirect change you did had negative consequences. Can I get you to look at it?

-- KennethLavrsen - 30 Jun 2009

I've tried to reproduce this using several of the suggestions here, and I can't. There has to be something about the configuration, either Apache or Foswiki, that is affecting this.

Note that I have seen cases where a login redirect after an access violation takes you to the wrong topic; but never on clicking "Log In".

-- CrawfordCurrie - 03 Jul 2009

I've replicated it in the simplest form by untarring 1.06 and placing it in /var/www/foswiki, then generate an Apache config like this one.

Restart apache, do initial configure.

Register a user.

Close all browser instances.

Open new browser and log in to your new server. In Firefox you should get the error I first reported.

Every test I've done with that type of Apache config has this problem.

If I configure without short url rewriting like this, it works correctly, but I don't want my users to have to know http://server.tld/bin/view/Main/WebHome just to get started.

I can also configure to a path off the root url for access like http://server.tld/foswiki with or without short urls like this and it works fine.

-- DonWennick - 03 Jul 2009

I'm getting the same error in my foswiki installation, running in a Debian machine and using the Foswiki debian pacakges. It seems to be something related to the "short urls" feature and I couldn't solve the problem yet.

Has someone any tip about how to solve the problem and keep the short url's working?

-- ArthurFurlan - 10 Jul 2009

OK, so it seems to be related to short URLs. I don't use this feature myself, so I'm looking for guidance from those who do.

-- CrawfordCurrie - 13 Jul 2009

I solved (not fixed) this issue by editing the /var/lib/foswiki/lib/Foswiki.pm file and disabling the "foswiki_redirect_cache" feature. I don't know the foswiki's source and I'm not a perl programmer too, so I hope my patch helps the foswiki's developer to really fix this issue.

I added my patch at this page: http://foswiki.org/pub/Tasks/Item1766/Foswiki.pm.diff

-- ArthurFurlan - 15 Jul 2009

Arthur Furians observation obviously is not a fix.

Crawford did you try the configuration DonWennick points to in his 03 Jul 2009 comment?

-- KennethLavrsen - 29 Jul 2009

Looking at some recent changes I wonder of the fixes in distro:795c25df2d95 and distro:5bb5b172f678 could also have fixed this?

-- KennethLavrsen - 06 Aug 2009

Disabling the redirect cache is not a solution; it's not a "feature", it's a critical part of how it works

I configured a test system (1.1) as identically as I could given the information given here. I don't have any problem. So:

1. The apache rewrite rules are different somehow
2. some setup in LocalSite.cfg is different
3. the problem has been fixed in the interim

I have not configured a 1.0.6 system (I have run out of time to look at this).

-- CrawfordCurrie - 06 Aug 2009

I will try to get a test rig set up (I assume it needs to be SVN trunk) ASAP and try it out.

-- DonWennick - 06 Aug 2009

I tested this today with Foswiki-1.0.6, Sun, 21 Jun 2009, build 4272 (Debian 1.0.6-2 on Ubuntu 8.10), Firefox 3.0.13:

• toggle of the {Validation}{Method} from "strikeone" to "none": browser warning "infinite loop" (firebug: 21 GETs) after Edit a new topic, login, save, OK at the validation message...
• back to "strikeone": somehow I got the long number as topic name in the URL after trying the same, but I got a second login window. I also got a malformed URL: http://localhost/cgi-bin/foswiki/login/Main/WebHome?t=1249580142;nowysiwyg=1;origurl=//cgi-bin/foswiki/edit/Main/WebHome%3ft%3d1249580142%3bnowysiwyg%3d1 after trying to edit an existing topic.

-- WolfgangRaus - 06 Aug 2009

Wolfgang, you said distro:5bb5b172f678 (see Tasks.Item1830) didn't fix anything.

Could you try debugging it please? Set the validation code into debug (edit lib/Foswiki/Validation.pm, and look for sub TRACE { 0 } (should be line 53), replace the 0 with a 1), try again your scenario, and check your apache logs. Then, please paste the output here so we can have a look at it. The only interesting lines should begin with V:.

The problem fixed by distro:5bb5b172f678 was that, when set to none, the leading question mark is passed along with the nonce (normally the JS removes it when it calculates the nonce with the secure cookie, but as the JS isn't activated...)

It seems your problem is different, so maybe looking at what the server thinks the nonce is, and what the client sends, can help.

-- OlivierRaginel - 06 Aug 2009

Here the logfile cutout:

[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE b1e10c2f410434d73154945a806359a1 1249590863
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 2729c946daa7129a37710df02ba68899 1249591043
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE f47abf3fc0c4c9d757c161ab990351a3 1249590743
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 34cd438a2d1a82d35eddf9e7c34f7c37 1249590619
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE e3c27907feaba2b09738f363f5d0f996 1249591251
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 8e8e059ee916c346bd45084acca282f3 1249590837
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 585a1dd888ff2f1d630e3a7fc5ad8207 1249590830
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE f84642d913323a5d47a094cef349373a 1249591247
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 1541b201f6af621d90157b5a9588c76f 1249590680
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE f9bc8f6242bb346b3a7da2545ccdf9db 1249590858
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE aea8bf878e3a8477a62d44d90249a02e 1249590812
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE f45a016ce4cae9c97b81393797239305 1249590891
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 010dc607bbd2a04f24ca52ee3e457bad 1249590818
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE a31e034f300e531add2e9e575b6f8102 1249590925
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE aca32d8a01068686953952290deabbdd 1249590959
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE f28f2cc6403584aba44069df3774838a 1249591056
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 5b5c3e8a64177f49ec7354d172ab336f 1249590728
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 49b8e8fc27e373e1f3cbe81d8dfee2b8 1249590629
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE fc3cae4b24606799c5e2f5078cebd36f 1249591461
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE c9a4d5a7d9c0827d54c6fbd1f0bfb5f5 1249590705
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 9ddae31e7cae4111edb2fe3b899113fc 1249591048
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 0ee3d1fd465a8ed57ca9f17f5b529b97 1249590568
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE cec141f19b7625e90807779be6ecb5eb 1249591464
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 1d6821e9a8b6d6ed6702f0dddf22788c 1249591055
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 9851aadcedfd270a0aba189502211850 1249590964
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 2be49ec5f97d9143ace3c3ec671526ce 1249590613
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE ef70c023756974411618e9445ceb84f4 1249590628
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 611c103a5f7259164fe8c816414eac93 1249590921
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE fce84ec44a37a0a2eb576af5b9e794a1 1249591025
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE 7dc5e283a45ded85df5a7debbe57d303 1249590560
[Thu Aug 06 22:54:29 2009] [error] [client 127.0.0.1] V: EXPIRE bf58e0e5c64568f9966bb7bc4c2d86a1 1249591032
[Thu Aug 06 22:55:06 2009] [error] [client 127.0.0.1] Premature end of script headers: configure, referer: http://localhost/cgi-bin/foswiki/configure

the above with {Validation}{Method} = 'none';

-- WolfgangRaus - 06 Aug 2009

and now with {Validation}{Method} = 'strikeone';

[Thu Aug 06 23:03:09 2009] [error] [client 127.0.0.1] Premature end of script headers: configure, referer: http://localhost/cgi-bin/foswiki/configure
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE 5940e8a729dc5ee8e161a05ccf5df042 1249592118, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE d2d5530093412f4c97fd75d487523106 1249592107, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE 277af711664a8cd3bb96784a1ce5d8a6 1249592101, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE 5d98aed85ff6dc268aed99d568bfb300 1249592133, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE 532d48b0d2cc48f630c16e437475e60c 1249592111, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE 2be2bb6ed5dfd053725e0909ed3be1ae 1249592138, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: EXPIRE 0f80ebd478c32302e281441010ec9226 1249592130, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: STRIKEONE 5dcf999d1266dc5879ea1829327262bc + 939d765fcab408051fb8f8f7b4b416fa = c0076521f389b68431a6bc1f336d16bd, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:22 2009] [error] [client 127.0.0.1] V: ADD c0076521f389b68431a6bc1f336d16bd(5dcf999d1266dc5879ea1829327262bc) = 1249596202, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:51 2009] [error] [client 127.0.0.1] V: STRIKEONE 9c9d65c052a1c86c5eba0805ed909425 + 939d765fcab408051fb8f8f7b4b416fa = 7fbea2e4c89dcc1e1c08b604f6fc27ca, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome
[Thu Aug 06 23:03:51 2009] [error] [client 127.0.0.1] V: ADD 7fbea2e4c89dcc1e1c08b604f6fc27ca(9c9d65c052a1c86c5eba0805ed909425) = 1249596231, referer: http://localhost/cgi-bin/foswiki/view/Main/WebHome

In both cases: I applied the patch to Validation.pm, set TRACE to { 1 }, logged off and tried to edit the Homepage. After login, the URL http://localhost/cgi-bin/foswiki/login/Main/WebHome?t=1249592626;origurl=//cgi-bin/foswiki/edit/Main/WebHome%3ft%3d1249592626 could not be loaded.

-- WolfgangRaus - 06 Aug 2009

Don, yes, if you can test on trunk that would be a big help. We have to try and eliminate as many variables as possible, and that means reverting to an "out of the box" configuration (i.e. no extra extensions installed other than the basic set) and then identifying the minimum changes to the configuration that inspire the error.

The key considerations are likely to be the apache config, and exactly how you have set up the rewriting rules, and the values of PubUrlPath and ScriptUrlPath from LocalSite.cfg. I tried what you described, and it worked fine, so there has to be some other subtle difference.

Please also test with the shorter URL config and the validation method set to "none" (restart the server).

-- CrawfordCurrie - 07 Aug 2009

We got the same problem here since the upgrade to 1.0.6. (debian packages). We also use the short URL configuration and PatternSkin (with the gray frame). But we are not using NatSkin/NatSkinPlugin, LdapContrib/LdapPluginNg or TemplateLogin with LdapUserMapping.

Due to some inconsistent behavior -- the error didn't appear all the time --, I tracked it down to something which may be of importance for fixing the bug:

• If you log in from just the host URL, e.g. http://XXX.xx/, you will get the error as described above. This is because the origurl is set to "/", which you can see with a mouse-over on the Log In link:
  http://XXX.xx/cgi-bin/foswiki/login/Main/WebHome?origurl=/
• If you log in from a full path URL of any existing topic, e.g. http://XXX.xx/Main/WebHome, the origurl URLPARAM will be set correctly (here: /Main/WebHome ) and the login process will work flawlessly:
  http://XXX.xx/cgi-bin/foswiki/login/Main/WebHome?origurl=/Main/WebHome

So in case of the host URL, the Log In link is correct, regarding the path, but the origurl parameter is wrong.

-- PhilippLeufke - 13 Aug 2009

I just grabbed the trunk & minimal plugins from svn and got it running in a fresh server instance.

Using short url settings as before, and strikeone, it still produces the same problem, but as PhilippLeufke notes, it is only when you are at the url "http://server.tld" when you click Login, and not if you are at something like "http://server.tld/bin/view". I noticed that origurl=/ parameter before too and never dug deeper into it.

Using the short url config and validation "none" appears to work correctly.

-- DonWennick - 14 Aug 2009

As the issue only happens when the url is like http://XXX.xx/ (i.e. only a slash and not for a page), then adding the following to Apache will rewrite this URL to http://XXX.xx/Main/WebHome, which will work around the issue until it is fixed.

RewriteRule ^/$      /Main/WebHome   [L,NE,R]

-- AndrewJones - 19 Aug 2009

Don't seem to get this workaround running. I tried to add it to /etc/fowsiki/ShorterUrl.conf or /etc/fowsiki/apache.conf...

Where did you add it? Can you post the config?

-- PhilippLeufke - 19 Aug 2009

Where the ApacheConfigGenerator writes the short URLs support, as follows:

# Support for short URLs

Alias / /path/to/foswiki/bin/view/
RewriteRule ^/+bin/+view/+(.*) /$1 [L,NE,R]
#RewriteRule ^/+bin/+view$      /   [L,NE,R]
RewriteRule ^/+bin/+view$      /Main/WebHome   [L,NE,R]
RewriteRule ^/$      /Main/WebHome   [L,NE,R]

I think it would be around line 30 if you used the ApacheConfigGenerator unmodified.

-- AndrewJones - 19 Aug 2009

Now your workaround works. Thanks a lot! (I tried first with the ShorterUrl.conf and didn't get it working, but I'm not an apache2 expert...)

-- PhilippLeufke - 22 Aug 2009

Unfortunately, none of the above works for me. I just can't log in to my wiki anymore after upgrading it from twiki to foswiki 1.0.6. Logging in either gives me a redirect to https://foswiki_redirect_cache/something or just another logon prompt without any message about why i am not logged on. Will now downgrade to twiki again, i need access to my wiki dammit.

-- KoenMartens - 23 Aug 2009

We seem to be running into a version of this related to creating webs. Saves so far seem unaffected... Will test some of the conf hacks above and see if any work. Are there critical reasons not to just run 1.0.5 in the interim?

-- DrewStevenson - 24 Aug 2009

DonWennick et al, please try the following patch (the patch is against the Release01x00 branch and it may not be positioned exactly right in 1.0.6, but you should be able to get the flavour). let me know if this resolves the original problem.

Any other problems not addressed by this fix should be reported in separate tasks, please.

Index: lib/Foswiki.pm
===================================================================
--- lib/Foswiki.pm   (revision 4728)
+++ lib/Foswiki.pm   (working copy)
@@ -899,6 +899,9 @@
             # Redirecting from a post to a get
             my $cache = $this->cacheQuery();
             if ($cache) {
+                if ($url eq '/') {
+                    $url = $this->getScriptUrl(1, 'view');
+                }
                 $url .= $cache;
             }
         }

The problem arises because the origurl is a url relative to the current server. As long as you only add parameters to this URL, it will remain pointing at the same server. However when we changed to using the path_info to encode the redirect cache, this suddenly became interpreted as a URL to a different site. e.g.

• No URL rewriting:
  • origurl: /bin/view/Blah/BlahBlah
  • redirect url: /bin/view/Blah/BlahBla/foswiki_redirect_cache/09a239875bd984
• With URL rewriting:
  • origurl: /
  • redirect url: /foswiki_redirect_cache/09a239875bd984

I changed to the path rewriting approach to simplify the URLs, because passing parameters to 302 redirects is not good practice, and because it "just worked". I didn't anticipate the effect of URL rewriting.

-- CrawfordCurrie - 29 Aug 2009

Crawford, the patch works for me. Logging in from the minimal url (https://foswiki.sonologic.nl/) now works! Thanks.

-- KoenMartens - 29 Aug 2009

Can anyone find other examples of this? Or does it only affect URLs rewritten from / ?

-- CrawfordCurrie - 31 Aug 2009

This seems to be working well for my installations too, thank you!

-- DonWennick - 31 Aug 2009

I have only had it when URLs are rewritten from /. The patch looks like its working for me. Thanks.

-- AndrewJones - 03 Sep 2009

With 3 times positive feedback it was time to get the fix checked in. I gave a hand with that.

Positive feedback still welcome.

-- KennethLavrsen - 03 Sep 2009

Worked for my site; thank you very much.

-- ThomasPHaeck - 03 Sep 2009

I've noticed another variation on this one on a patched debian system (ok, 2 now)

in my debian packages, I have a ShorterUrl.conf (that I don't tell everyone about)

<Directory /var/www>
    RewriteEngine on
    RewriteRule ^$ /cgi-bin/foswiki/view/$1 [PT] [L]
    RewriteRule ^([A-Z].*) /cgi-bin/foswiki/view/$1 [PT] [L]
</Directory>

and using this, the patch above doesn't work.

adding a rewrite rule as the ApacheConfigGenerator does to hardcode / to /Main/WebHome isn't an option for me, as I use HomePagePlugin to make / goto different places depending on context.

as you can see from the rewrite's, the foswiki system isn't at the root of the web server at all, and so http://server/foswiki_redirect_cache/112341234 isn't being sent to foswiki either.

and so thats yet an old functionality that's been broken by the change from urlparam to request path

ACTUALLY, the / to /Main/WebHome isn't needed - what is missing, is a new RewriteRule...

<Directory /var/www>
    RewriteEngine on
    RewriteRule ^$ /cgi-bin/foswiki/view/$1 [PT] [L]
    RewriteRule ^([A-Z].*) /cgi-bin/foswiki/view/$1 [PT] [L]
    RewriteRule ^(foswiki_redirect_cache.*) /cgi-bin/foswiki/view/$1 [PT] [L]
</Directory>

then there was an odd instance where I got a URL like

http://10.1.1.6/cgi-bin/foswiki/view/Fosiki/WebHome/foswiki_redirect_cache/31f7e8dc695a9f335f613da2b762bf3a/foswiki_redirect_cache/31f7e8dc695a9f335f613da2b762bf3a

with an error complaining that the foswiki_redirect_cache web does not exist.

-- SvenDowideit - 05 Sep 2009

I am getting very concerned about this bug.

• It was a fix for a problem that only the developer making the fix had. I do not have the impression that many were affected by it.
• It has delayed the release of 1.0.7 since June
• Quite many people have reported the problem and this means a magnitude more people who are always silent also has it. Some have reported that they had to revert to 1.0.5 because of this bug.
• A recent fix was done (which I had to check in). But now the fix is reported to still not resolve the problem.

My conclusion: We need to go back to the original behaviour where the redirect cache was given as a query parameter. And the original problem will have to be fixed some other way.

Crawford are you taking the needed actions to solve the problem you created? Or do I revert the changes in Item1711? It was a simple fix which is easy to revert.

-- KennethLavrsen - 05 Sep 2009

I fixed the problem with URL rewriting where the foswiki is at the root of the server. Sven is reporting some other configuration which exhibits problems, but he hasn't given enough details to comment further (other than his fix, which is to add a rewriting rule).

I made the change originally to support authentication systems that do not support parameter passing. Simple reverting Item1711 will break those systems, which is a less than ideal approach. So, if you plan to reintroduce passing the cache address in parameters, then I'm fine with you doing that as long as the cache address can still be passed in the URL as an alternative i.e.

• If there is a foswiki_redirect_cache url parameter
  • get the cache address from it
• otherwise
  • get the cache address from the URL

and on the URL composition side, it needs to decide whether to encode the cache address in a parameter, or in the path info. I guess the behaviour has to be selected by configuration; is there a $Foswiki::cfg{UsingUrlRewriting} flag (or similar) to warn Foswiki that URLs are being mangled by Apache? If not, there needs to be. None of this is rocket science.

Later: decided I couldn't face a discussion about this, so did as described above myself.

-- CrawfordCurrie - 05 Sep 2009

I have created Item2083 to track improvements of the foswiki_redirect_cache in a 1.1 context

For 1.0.7 the solution we have now with the default value will be OK and I would like a closed bug item for the 1.0.7 release.

I have moved the last postings from this topic to the new 2083

-- KennethLavrsen - 16 Sep 2009