XHR redirects
in [JavaScript]
|
From: Richard Cornford on 26 Feb 2010 12:06 On Feb 26, 3:24 pm, Jorge wrote: > On Feb 26, 3:56 pm, Richard Cornford wrote: <snip> >> I haven't ever tired re-directing across domains. It is >> asking for trouble. I would expect an XML HTTP request >> object to deny access to any response from a different >> domain. > > Denying access to the response might be a good thing, > yes, but, by then it might be too late already. I think > that the 2nd request -to the redirected domain/resource- > should -probably- be discarded -never made- by the XHR > object... ¿? Or maybe not, that's why I'm asking. Look at what RFC 2616 has to say on the subject. Among other things, it says that automatic redirecting following a 30X response is only allowed if the second request uses the GET or HEAD methods, and that GET and HEAD are both idempotent. So there should (assuming whoever is responsible for the redirected/redirecting resources understood the responsibilities of their task) be no significant consequences of making the request or not making it. If an XML HTTP request object was going to refuse to automatically redirect then it should present the status 30X response to the calling code, and let it work out what to do next. >>> What happens if the redirect is to bank.com/ >>> operate/transferNow?amount=10000&destAccount=myAcctNumber ? >>> Would bank.com cookies be sent along in the 2nd -redirected- >>> request ? > >> Cookies should follow the rules for cookies. Which cookies >> go with which requests depends on their (actual or implied) >> Path and Domain parameters. > > But you know that there are circumstances under which existing > cookies are *not* sent. That is what the rules for cookies say is possible. So your point is? >> However, it would be reckless to be sending instructions to >> be acted upon (especially in a financial context) in a cookie. > > I was thinking about session ID cookies. If ever there was a type of cookie that should be restricted to a single domain it is a session ID cookie. Richard.
From: Jorge on 26 Feb 2010 12:26 On Feb 26, 6:06 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On Feb 26, 3:24 pm, Jorge wrote: > > > On Feb 26, 3:56 pm, Richard Cornford wrote: > <snip> > >> I haven't ever tired re-directing across domains. It is > >> asking for trouble. I would expect an XML HTTP request > >> object to deny access to any response from a different > >> domain. > > > Denying access to the response might be a good thing, > > yes, but, by then it might be too late already. I think > > that the 2nd request -to the redirected domain/resource- > > should -probably- be discarded -never made- by the XHR > > object... ¿? Or maybe not, that's why I'm asking. > > Look at what RFC 2616 has to say on the subject. Among other things, > it says that automatic redirecting following a 30X response is only > allowed if the second request uses the GET or HEAD methods, and that > GET and HEAD are both idempotent. So there should (assuming whoever is > responsible for the redirected/redirecting resources understood the > responsibilities of their task) be no significant consequences of > making the request or not making it. > > If an XML HTTP request object was going to refuse to automatically > redirect then it should present the status 30X response to the calling > code, and let it work out what to do next. ISTM -looking at it into w3.org- that it will throw either a security err or a network err: <quote> If the response is an HTTP redirect: If the redirect does not violate security (it is same origin for instance), infinite loop precautions, and the scheme is supported, transparently follow the redirect while observing the same-origin request event rules. HTTP places requirements on the user agent regarding the preservation of the request method and request entity body during redirects, and also requires end users to be notified of certain kinds of automatic redirections. Otherwise, this is a network error. </quote> > >>> What happens if the redirect is to bank.com/ > >>> operate/transferNow?amount=10000&destAccount=myAcctNumber ? > >>> Would bank.com cookies be sent along in the 2nd -redirected- > >>> request ? > > >> Cookies should follow the rules for cookies. Which cookies > >> go with which requests depends on their (actual or implied) > >> Path and Domain parameters. > > > But you know that there are circumstances under which existing > > cookies are *not* sent. > > That is what the rules for cookies say is possible. So your point is? That it might have been that this were another of these circumstances. > >> However, it would be reckless to be sending instructions to > >> be acted upon (especially in a financial context) in a cookie. > > > I was thinking about session ID cookies. > > If ever there was a type of cookie that should be restricted to a > single domain it is a session ID cookie. Exactly. Therefore my worry. Thanks, -- Jorge.
From: Stefan Weiss on 26 Feb 2010 12:31 On 26/02/10 18:06, Richard Cornford wrote: > On Feb 26, 3:24 pm, Jorge wrote: >> On Feb 26, 3:56 pm, Richard Cornford wrote: > <snip> >>> I haven't ever tired re-directing across domains. It is >>> asking for trouble. I would expect an XML HTTP request >>> object to deny access to any response from a different >>> domain. >> >> Denying access to the response might be a good thing, >> yes, but, by then it might be too late already. I think >> that the 2nd request -to the redirected domain/resource- >> should -probably- be discarded -never made- by the XHR >> object... ¿? Or maybe not, that's why I'm asking. > > Look at what RFC 2616 has to say on the subject. Among other things, > it says that automatic redirecting following a 30X response is only > allowed if the second request uses the GET or HEAD methods, and that > GET and HEAD are both idempotent. So there should (assuming whoever is > responsible for the redirected/redirecting resources understood the > responsibilities of their task) be no significant consequences of > making the request or not making it. > > If an XML HTTP request object was going to refuse to automatically > redirect then it should present the status 30X response to the calling > code, and let it work out what to do next. That is exactly what Firefox does. Opera also won't follow the redirect automatically, but its xhr.status value is 0 for some reason. I didn't try any other browsers, but I would be very surprised if any of them (the more recent ones, at least) could be tricked into sending an XHR which violates the browser's security policies by something as simple as an HTTP redirect. -- stefan
From: Richard Cornford on 26 Feb 2010 12:40 On Feb 26, 5:31 pm, Stefan Weiss wrote: > On 26/02/10 18:06, Richard Cornford wrote: <snip> >> If an XML HTTP request object was going to refuse to >> automatically redirect then it should present the status >> 30X response to the calling code, and let it work out >> what to do next. > > That is exactly what Firefox does. Opera also won't follow > the redirect automatically, but its xhr.status value is 0 > for some reason. > > I didn't try any other browsers, but I would be very surprised > if any of them (the more recent ones, at least) could be tricked > into sending an XHR which violates the browser's security policies > by something as simple as an HTTP redirect. Why not? For a very long time it has been possible to 'trick' a browser into making a request to another domain by setting the - src - of a - new Image(); -. Making the request or not is not that important so long as access to the result is denied. Richard.
From: Scott Sauyet on 26 Feb 2010 12:58
On Feb 26, 12:40 pm, Richard Cornford wrote: > On Feb 26, 5:31 pm, Stefan Weiss wrote: >> I didn't try any other browsers, but I would be very surprised >> if any of them (the more recent ones, at least) could be tricked >> into sending an XHR which violates the browser's security policies >> by something as simple as an HTTP redirect. > > Why not? For a very long time it has been possible to 'trick' a > browser into making a request to another domain by setting the - src - > of a - new Image(); -. Making the request or not is not that important > so long as access to the result is denied. .... and if the request is actually idempotent. I know GET and HEAD requests are supposed to be, but we all remember the havoc caused with many sites when some prefetching was released (was it Google Web Accelerator?) -- Scott |