The objective is to redirect a user after he/she saves a form, to a success page. The question is what's the best redirect method - redirect code - that should be used?
HTTP Status Codes
Technically, I think 303 is most appropriate, assuming that you always want the redirect to be executed as a GET, per the spec.
However, that won't be supported by HTTP 1.0 clients. All modern browsers should be good with HTTP 1.1 though.
302 redirects will work fine, but if browsers ever decide to implement the spec correctly (which is unlikely at this point), this may break apps because technically, it's supposed to use the same method as the original request (so if you post, it will post for the redirect as well). In fact, most web frameworks' built-in redirect functionality uses 302 redirects, not 303's, but that's just because the browsers have created a de facto standard.
Related
When a request for an HTML page responds HTTP 302 Found (aka 'temporary redirect') FireFox loads the redirect page 'in-place', without keeping the originally opened URL U in 'back-button history'.
One popular use for 302 (and a correct use of the code, I think) seems to be redirecting to a /cookieAbsent page, alerting the user that their browser doesn't 'support' (perhaps more likely the user has disabled) cookies.
The consequence of this browser behaviour is that, if the user decides to enable cookies, reloading of course just reloads (the server couldn't send you back, reliably, if it wanted to) /cookieAbsent which is no good, and the back button goes back to wherever they were prior to opening (whether by hyperlink or typing) the original U. This would make sense to me for 301 Moved Permanently (aka 'permanent redirect'), but seems undesirable for 302, especially when used like this.
If I am implementing a browser - or, perhaps, hoping to report a bug or feature request in an existing one - is this behaviour required by a common specification, or is it simply up to the browser to do as it sees fit?
You can find this very relevant bug from 20 years ago (!) on mozilla bugtracker
A short summary of the justification seems to be they did it that way because some websites apparently used 302 the wrong way as a redirect path
/product?limitedtimetoken
302 to
/product?superproduct
302 to
/superproduct
and some got used to the "wrong" behavior of not saving and used it for pretend security
/checkauth
302 to
/connected?gotoaccount
302 to
/account
and while it was "technically right" to save those in history it was just the wrong behavior for end users to have all those middling urls saved, since those were fake 302 that would always redirect in reality.
If you've ever had a case of "the back button of my browser doesn't work it always go back forward" that you can see sometimes it's easy to understand their reasoning.
They mention that it was also what IE and Netscape did, though I could not find the why for those (but I assume it's mostly the same: it would have been bad for the end user to have all that saved in history).
by the way, it makes no sense to undo "this change" - this change is the right
fix.. you're right that the site in question is doing the wrong thing, but we
should still be fixing this problem.
this patch makes mozilla behave identically to Netscape 4x and IE w.r.t. storing
redirect urls in global history. and it is important that we also implement
this behavior because (unfortunately) many sites have grown up depending on it
for some level of percieved security. this fact is something that can't be
changed overnight, nor will it help the reputation of mozilla to not compromise
on this issue.
Suppose URL $u$ redirects to URL $v$. Suppose also that $u$ is pushed to the history and then $v$ is pushed to the history. When the user clicks the back button, the user will be taken to $u$, which will redirect to $v$. The user will find himself in an infinite loop, making the back button useless.
This is because browser history does not (have to) conform to cache semantics.
The goal of the history (back button) is to present the user with the page that they would have gotten given the (possibly expired) responses the browser got earlier.
For a more detailed explanation you can look at: https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#history.lists
I am looking for a solution to interrupt or pause a 301 ( redirect ) request in Chrome dev tools. My scenario is I have an API integration with a local payment gateway which requires 301 redirect to their server ( HTTP GET and then redirect with 301 to an external URL). As 301 HTTP status code happens on the client-side so this can be compromised as the current system does not protect the integrity of the data, for instance, the amount to pay. I might send 100$ and the user might change it to 20$.
To prove this I need to stop the request manually which is very inconvenient and hard to test. I am looking for a solution that implements in one of my favorite browsers above that allows me to config to interrupt or pause the 301 HTTP status code so I can easily modify the value in the URL before resuming the request.
I found a chrome extension to solve this issue.
Requestly is easy to use and test. This is what being mentioned in the extension page:
Chrome Extension to modify HTTP requests (Setup Redirects, Run Custom
Javascript, Modify Headers
But my scenario is about modifying url query string - not being mentioned in the description but it works perfectly.
I am looking at my IIS web log and notice some log records with an sc-status of 302.
I did research and am only more confused.
At first, it looks simple, if a little vague.
"This is an example of industry practice contradicting the standard.
[...] Therefore, HTTP/1.1 added status codes 303 and 307 to
distinguish between the two behaviours.[25] However, some Web
applications and frameworks use the 302 status code as if it were the
303."
While I understand the concept, I am not sure which meaning to apply when viewing an IIS web log. Do I treat the 302 status code as a 303 ("See Other" -- a way to redirect to a new URL) or as a 307 ("Temporary Redirect")?
307 causes a redirect using the same "verb" that the original url was requested with. That allows POST data to be preserved. By contrast, 301/302 will always cause a GET of the new url, losing any POST data that may have been present.
As well, with 301/302, the browser can cache the response and always go to the new url, bypassing the original url. 307 requires that the original URL be hit again, even if it does end up being another redirect.
I need to redirect (after do something) to an URL from doView().
How is it possible?
Many thanks in advance,
From your tags I'm assuming you're writing a portlet, possibly including an actionhandler. Now as soon as you're coming to the render phase, you intend to redirect to a completely different URL (e.g. to redirect your browser to show something outside of the portal) - correct me if I'm wrong.
With this, HTTP redirect is out of the game if you want this to work reliably. (There has been a lively debate on the liferay forums on the reasons)
For this reason javascript is your friend if you intend on the redirect to happen during render phase. However, note that this still might interfere with user expectation: Imagine if two different portlets generate different javascript redirects - which one do you expect to win?
Architecturally it might be cleaner to trigger a redirect during the action phase, but that's not your question
On my website users can post stuff anonymously.
When they have posted something they will be redirected to their post, let's say:
http://example.com/post/2/title-of-the-anonymous-post
The user who submitted the post and the admins are the only ones with access to that post (until it is made public). Once it is made public the post would still be anonymous (i.e. people cannot see who submitted the post).
However, on that page there are also some external links. If the user decides to click an external link the target website has the ability to log the http referer (which would contain the link to the hidden page). This means it would be possible to find out who posted it once it is made public.
Is there a way to change the HTTP referer (/ referrer) when a users clicks on a link to another website?
By for example first redirecting the user to another url and let that page redirect to the external website:
user clicks on: http://example.com/referer-hider?url={urlencoded(url)}
and let the referer-hider redirect the user to the external page so that the referer will contain: http://example.com/referer-hider?url={urlencoded(url)}
Will this work? Or is there another solution for this (which doesn't require client side modifications)?
Since the referrer is provided by the browser to a web server, I only see two ways to insure that external sites don't get a view of this "hidden" URL.
First way would be (as you said) to remove the external links from your hidden page by running them through a redirector which uses header("location: ...");). Yes, that will work. You might just want to use this in general, so that you can track the exits from your site.
Second way would be to stop hiding this URL. It won't stay hidden forever, after all. A Google/Alexa/whatever toolbar hits it, and bam, it's indexed. So instead, build this hidden functionality into something session based. Make a script that changes its output depending on session variables, and only allow the hidden content to show up if people have logged in or previewed their post or whatever.
The third (and probably best) way would be to implement proper access control, so that anonymous users CANNOT visit the page with the restricted content. If you want an anonymous original poster to be able to visit THEIR OWN post, you can send them a cookie, then validate the cookie upon the visit to the unapproved post.
For example, upon submission for approval:
setcookie('postkey', mysql_insert_id());
Then:
$pieces=explode($_SERVER['PHP_SELF']);
$postid=$pieces[2]; // or whatever
if (!isset($_COOKIE['postkey'])) {
header("Location: http://example.org/");
} else if ($_COOKIE['postkey'] != $postid) {
header("Location: http://example.org/");
}
etc. You probably want better protection than this, but it should give you some ideas.
The HTTP referer is not transmitted by the browser when a link is going from HTTPS->HTTP. So a simple solution is to have an https redirect page: https://yoursite/redirect?url=... . However this page is also vulnerable to OWASP a10 - Unvalidated Redirects and Forwards, but that might not matter to you. Another solution that doesn't expose you to OWASP a10 is to use a free redirect service.
The Meta referrer proposal from Adam Barth would help with your case; in short you could tell browsers via a <meta> tag that the Referer header should be stripped on all outgoing links.
This isn't a complete answer since it's only implemented in Webkit thus far, but it's something to keep an eye on.