Item2597: login script redirect sometimes misses hostname part

This is really hard to reproduce. We have had users on IRC occasionally come in to talk about this, but nobody has been able to reproduce. Now I can reliably trigger it on a test installation of Foswiki 1.0.9-rc1 which runs in parallel to my production 1.0.8 installation.

This is not the normal sequence of events that naturally occur to trigger the bug; I can never quite remember how this pops up in normal use. I also use an unorthodox apache config (my own variant of ShortURLs)

So the following steps should not be discounted as an unlikely sequence; it's just another method of reproducing the bug.

• Logged out
• Edit a topic
• Redirected to login prompt URL:

  https://wiki.org/test/bin/login/Main/PaulHarvey?t=1262758695;origurl=/test/bin/edit/Main/PaulHarvey%3ft%3d1262758695

• Insert a '/' at beginning of origurl param, as follows:

  https://wiki.org/test/bin/login/Main/PaulHarvey?t=1262758695;origurl=//test/bin/edit/Main/PaulHarvey%3ft%3d1262758695

• Hit enter in the address bar (Iceweasel 3.0.12)
• Enter login details, submit
• Browser redirected to a URL without hostname, Ie.:

  https://test/bin/edit/Main/PaulHarvey?foswiki_redirect_cache=deadbeef1234567890abcdef

Confirmed on a vanilla out of the box Foswiki-1.0.9-rc1, will attach apache config

-- PaulHarvey - 06 Jan 2010

• foswiki-109.conf: foswiki-109.conf

---

I can't see much wrong with that. The protocol is optional, and an absolute URL can simply be a double-slash and a server name, optionally followed by a path on that server. By adding the extra / at the start of the URL, you are changing it from a URL that is relative to the current server, to an absolute URL on server 'test'.

I'm sure you are seeing a bug somewhere, but you are not reproducing it above, as the code correctly handles your edited URL.

With regards to the "real" bug, are you using URL rewriting?

-- CrawfordCurrie - 06 Jan 2010

Yes, I am using URL re-writing. I am pretty sure that each case of missing hostname redirects that I've had are a result of // URLs. But these aren't necessarily a result of dodgy apache rules, Eg.,

• Logout of this topic
• Now click http://foswiki.org//bin/edit/Tasks/Item2597, which looks like

  [[http://foswiki.org/%SCRIPTURLPATH{"edit"}%/%WEB%/%TOPIC%]]

  in TML
• Login
• Redirected to hostnameless URL

Is '//' really the way the origurl takes you to an absolute URL? Shouldn't it have a full protocol:// specification instead?

I've had at least one user on my own wiki come across this problem. It was with an attachment. They said it didn't work the first time they clicked, but did when they tried again. I suppose this person was logged in the second time they tried to access the protected attachment URL. I am grepping my server logs for clues.

-- PaulHarvey - 06 Jan 2010

The problem seems to be the redirect to the // instead of just /

Either we have a bug in redirect code or a bug in the recommended way to setup short URLs.

I would hope there is a ApacheConfigGenerator fix for this and I doubt this is a new thing in 1.0.9.

In fact - does the current ApacheConfigGenerator generate rewrite rules that makes double //?

This foswiki.org site does not do it.

-- KennethLavrsen - 07 Jan 2010

Paul explained what the actual use case it.

People simply use the form http://somehost/%SCRIPTURLPATH{"edit"}%/%WEB%/%TOPIC% because this looks natual. But the SCRIPTURLPATH starts by a / and this creates the //

I think it should be addressed. But it is not an urgent bug because correct use of SCRIPTURLPATH works. Downgrading to normal.

-- KennethLavrsen - 09 Jan 2010

IRC chat today points to RedirectPlugin as another culprit, generating foo.com//urls

-- PaulHarvey - 17 Feb 2010

Give Tasks.Item8599 a look if somebody is looking at fixing this (probably me I suppose)

-- PaulHarvey - 22 Feb 2010

See also: Item2288 and Item2083

-- PaulHarvey - 21 Apr 2010

This is still happening on trunk r7231

Patch below "fixes" the problem... personally I think it's an acceptable solution:

• It's the web browser here trying to interpret //foo/bar as an absolute URL.
• In that situation there is nothing you can do in Foswiki to even detect you are getting these errors:
  • there are no log hits, browser is trying to access a null hostname
  • your only feedback will be from users
    • who may or may not get around to informing a site admin
    • because their second attempt at visiting a foo.com//foo/bar link will mysteriously work after having logged in
    • even if they do inform the site admin that "the link went blank" (will they mention it was blank after log-in?), will they remember which "bad' link they clicked?

On my own wiki, we've had a person originally create a topic which used something like

[[%PUBURLPATH%/Foo/Bar]]

. Also, in some circumstances (Item8551) RedirectPlugin will happily generate //links through no fault of the user.

On the other hand, I can appreciate that second-guessing URL strings could be considered bad.

---

Adds a test:

• Item2597.diff: Item2597.diff

-- PaulHarvey - 21 Apr 2010

Not sure why this was left waiting for me, I don;t have any more to offer on it....

-- CrawfordCurrie - 23 May 2010

You gave me feedback on IRC instead of here. You said it would be better to emit an inline error if a link is generated than patch up the redirect logic.

I don't think this will catch as many scenarios as first patch here would (eg. manual < a href="//link... vs [[//link]] ), but it would be better than nothing.

-- PaulHarvey - 24 May 2010

This still fails in 1.1.3beta1 - the redirect looses the hostname. From chrome: The webpage at http://bin/edit/Tasks/Item2597?validation_key=23bf824759ff1e187e4428d0d78e8ee2

-- GeorgeClark - 13 Mar 2011

I believe that this is resolved on 1.2. The origurl parameter is no longer passed as a query parm in the location bar.

-- GeorgeClark - 09 Jan 2015