Item9561: Anchor gets lost after logging in - again

If you follow a link with an anchor - like http://trunk.foswiki.org/System/FormattedSearch#Animated_Example - and you need to log in to view the page, the anchor gets lost.

-- ArthurClemens - 26 Aug 2010

Seems we already fixed that bug, but as Arthur said, we never wrote a unit test because it's complex. I'll try to write one anyway.

-- OlivierRaginel - 26 Aug 2010

Ok, in fact, I doubt there is any easy way to fix that. Bottom line:

ANCHORS ARE NOT SENT TO THE SERVER.

So, this means we have several choices:

• We give up
• We re-code the login into AJAX
• We hack it through, I've read that sometimes putting some dummy query string might lure some browser into sending it
• We generate "dual anchors":
  • If the user is not logged in, and we generate a link with an anchor, with add some ?anchor=blah#blah to it.
  • Problem: his won't work for direct access

Any other ideas?

Arthur, the hack you put with the splitAnchorFromUrl, I have no idea when it's used, as I doubt we ought to ever see any anchor ever on the server-side.

-- OlivierRaginel - 31 Aug 2010

The 'hack' is there for the case an achor is passed in a redirectto. For instance:

<input type="hidden" name="redirectto" value="%TOPIC%#SomeAnchor" />

If this works depends on:

1. The invoked script must recognize redirectto. Edit and save do, view does not.
2. No login step is required, as login will loose the redirectto parameter

I think 2 fixes are needed:

1. Login should pass redirectto instead of throwing it away
2. Login could implement the implicit redirectto by passing the anchor instead of making the # sign %23

-- ArthurClemens - 31 Aug 2010

But that won't fix the current problem... Here, the login script has no idea there is supposed to be some anchor, because the browser will never send it to it. So I have no idea what you want to achieve here...

-- OlivierRaginel - 01 Sep 2010

About the what: You get a link to a section within a long topic. So the url has an anchor. To view you need to log in (might be a restricted page). You log in, view the page. Anchor is lost, you're lost.

About the how: apparently the anchor is not passed to the server, so we need to pass this to the form using javascript.

-- ArthurClemens - 01 Sep 2010

Yes, as it turns out, this should work in most cases, and if the user has javascript disabled, then.. sorry dude, but we can't help you.

And it shouldn't be that hard to make either, so I might give it a try unless somebody beats me to it. I'll re-iterate here the idea I gave on IRC:

• The user clicks a link with an anchor
• The browser sends the GET, but keeps the anchor to itself, as per the RFC
• The server redirects with a 302, therefore the anchor is kept
• The browser gets the login page. In its URL / location, the anchor is there, but as soon as the user clicks the submit button, it's lost
• TODO: The login page grabs this anchor from the location, and puts it into some hidden new form field (or hacks the current form, but that's going to be more work for no gain)
• The user clicks submits, submitting the form with the hidden param anchor=blah
• The server checks the credentials, they fail, so it gives the user the login prompt again
• TOCHECK: The login form shall not do anything with the anchor, as the hidden param is already there. Or at least it shouldn't append, but just replace the current value
• User submits the proper credentials
• Server redirects to the proper URL, with the anchor appended
• User is happy

-- OlivierRaginel - 02 Sep 2010

TODO is done TOCHECK doesn't need to be done, because when the user clicks the submit button, the anchor is lost, and it is saved as a form parameter.

So for me, the one-liner fix should do it. And if JS is disabled, then the onsubmit will not trigger, and the user will loose the anchor. Nothing we can do about that.

-- OlivierRaginel - 05 Sep 2010

Committing a unit test I wrote, even though it will never test that until we have Selenium working, I still struggled some time to write such a test, and it could be useful to someone else.

-- OlivierRaginel - 12 Sep 2010

Commits to AccessControlTests never made it over to Release01x01. Fixing.

-- PaulHarvey - 02 Oct 2011

Commenting is disabled while not logged in