Question

For a web app I want to let users review and edit a record they made previously through a browser form. In their confirmation mail, they get an access link with a secret token, like http://myapp.com/edityourstuff/hdD8sF2m Clicking this link shows them a form in which they can edit the existing data they submitted earlier.

This is not as secure as a username/password combination, but much more convenient and suitable for my situation.

However, I want to make this as secure as possible.

GET URLs

If the link containing the secret access token is disclosed, unauthorised people can access the data. My concern here is about shared/public computers.

I was planning to tackle this problem with the following pattern:

1. Access to /edityourstuff/ds8sdfhe via link in email
2. Start a session, store the secret token in there
3. redirect to clean /edityourstuff without token
4. The app now has access to the token in the session and can display the form accordingly. And the URL bar does not show it.

My question now is: Do browsers store the initial URL, that immediately redirects to the clean URL in their history?

I know that the different HTTP redirect status codes (301, 302, 303) have different use cases in theory. Is there any information on how different browsers treat the different redirect codes in respect to (not) storing the initial URL in browser history?

Answer 1

I just did some quick testing myself, with Firefox 7.0.1

When using the above pattern, no matter if 301, 302 or 303 redirect, Firefox does not return to the initial URL when clicking the back button. However, it is shown in the full browsing history and is part of the URL completion list of the browser bar.

This is exactly the drawback I was hoping to avoid.