XHR redirects

J

Jorge

Hi,

Let's say a page does an XHR to theSameDomain, and the response is a
redirect to a another resource in another domain. Is that legal ? Will
such an XHR succeed ?

TIA,
 
R

Richard Cornford

Let's say a page does an XHR to theSameDomain, and the response
is a redirect to a another resource in another domain. Is that
legal ?

Any normal HTTP exchange is 'legal'. (Some may still not be supported
(such as some operations))
Will such an XHR succeed ?

Succeed is too subjective. If you make an XML HTTP request and the
status of the response is one of the redirection statuses with a new
URL location then that is success in one sense (and the client-side
code can observe the status and the alternative URL and make some
decision about how it is going to act).

I suspect that you mean; will the XML HTTP request system
automatically act on the redirection and return the response from that
alternative source. To which the answer is that mostly they will.
There were Opera versions that did not, but they had to change that as
web developers mostly cannot cope with HTTP and so were declaring
Opera broken when it only did what they asked for instead of what they
expected.

Richard.
 
J

Jorge

Any normal HTTP exchange is 'legal'. (Some may still not be supported
(such as some operations))


Succeed is too subjective. If you make an XML HTTP request and the
status of the response is one of the redirection statuses with a new
URL location then that is success in one sense (and the client-side
code can observe the status and the alternative URL and make some
decision about how it is going to act).

I suspect that you mean; will the XML HTTP request system
automatically act on the redirection and return the response from that
alternative source. To which the answer is that mostly they will.
There were Opera versions that did not, but they had to change that as
web developers mostly cannot cope with HTTP and so were declaring
Opera broken when it only did what they asked for instead of what they
expected.

Ok. Thanks, Richard. One more question would be, isn't that a blatant
violation of the SOP ? 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 ?
 
R

Richard Cornford

Ok. Thanks, Richard. One more question would be, isn't that
a blatant violation of the SOP ?

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.
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.

However, it would be reckless to be sending instructions to be acted
upon (especially in a financial context) in a cookie.

Richard.
 
J

Jorge

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.
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.
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.
 
R

Richard Cornford

On Feb 26, 3:56 pm, Richard Cornford wrote:

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.
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?
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.
 
J

Jorge

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.
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.
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,
 
R

Richard Cornford

On 26/02/10 18:06, Richard Cornford wrote:

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.
 
S

Scott Sauyet

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
 
R

Richard Cornford

On Feb 26, 6:06 pm, Richard Cornford wrote:

ISTM -looking at it into w3.org- that it will throw either
a security err or a network err:

As I said, attempting a cross-domain redirect is asking for trouble.
<snip>

If you quote something you really should say what it is you are
quoting. Citing "w3.org" doesn't quite achieve that.
That it might have been that this were another of these
circumstances.

That what might be "another of these circumstances"?
Exactly. Therefore my worry.

What worry? If the cookie is set with no Domain the result is that it
is restricted to the domain that sets the cookie, and it will not be
sent with any requests to other domains. If a Domain is specified then
the UA should not send that cookie to any other domain.

Richard.
 
R

Richard Cornford

... and if the request is actually idempotent.

Alright, what 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?)

I have absolutely no idea what you are talking about.

Richard.
 
J

Jorge

What worry? If the cookie is set with no Domain the result is that it
is restricted to the domain that sets the cookie, and it will not be
sent with any requests to other domains. If a Domain is specified then
the UA should not send that cookie to any other domain.

This worry:

1.- You login to your bank at bank.com.
2.- Your browser has a session cookie for bank.com
3.- You open a new window.
4.- You enter someOtherSite.com.
5.- the page from someOtherSite.com does an XHR to someOtherSite.com
6.- the response to that XHR is a redirect to bank.com
7.- as a consequence of step#6, another request is made to bank.com
from the someOtherSite.com page
8.- Does the request at step 7 carry the cookie of step 2 (that's my
worry) ?
 
J

Jorge

As I said, attempting a cross-domain redirect is asking for trouble.

You said as well:

<quote>
I suspect that you mean; will the XML HTTP request system
automatically act on the redirection and return the response from
that
alternative source. To which the answer is that mostly they will.
</quote>
 
S

Scott Sauyet

Alright, what if the request is actually idempotent?

I meant to qualify your statement further. I mean that making the
request or not is not that important so long as both (1) access to the
result is denied and (2) the request is actually idempotent. A GET
request is supposed to be idempotent, but if it's not, then having
that request made on redirect could cause problems.
I have absolutely no idea what you are talking about.

At some point a few years back a browser plug-in was released; I
think it might have been Google Web Accelerator. [1] This tool was
supposed to speed up browsing by pre-fetching and caching links it
thought you might visit off the current page. It makes perfect sense,
except that a number of web applications out there had non-idempotent
GET request, especially hyperlinked "delete row" actions. People
started unintentionally altering all sorts of data using this tool.
Granted, it was the fault of people not smart enough to develop
properly with HTTP, but it was pretty easy to blame Google. The plug-
in is long gone now.

-- Scott
____________________
[1] http://en.wikipedia.org/wiki/Google_Web_Accelerator
 
I

Ivan S

5) TAN/TAC, SMS, USB dongle, etc: most banks require some external code
to finalize a transaction. Some send their customers a list of numbers
with pre-generated codes, some use SMS to send that code, some require a
USB device. I've even heard that some banks require you to boot from a
CDROM they provide. All of these can effectively foil CSRF attacks.


If I may add, hardware token generators and recently mobile software
token generators which are becoming very popular (at least in Europe).

Token number combins with (short) static password, as extra protection
in cases of token generator theft or something like that.


So ... there is always more than one way of authorization for banking
transations.
 
P

Peter Michaux

Hi,

Let's say a page does an XHR to theSameDomain, and the response is a
redirect to a another resource in another domain. Is that legal ? Will
such an XHR succeed ?

http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method

---------
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.

Note: 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.
 
T

Thomas 'PointedEars' Lahn

Peter said:
Jorge said:
Let's say a page does an XHR to theSameDomain, and the response is a
redirect to a another resource in another domain. Is that legal ? Will
such an XHR succeed ?

http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method
[...]

| Publication as a Working Draft does not imply endorsement by the W3C
| Membership. This is a draft document and may be updated, replaced or
| obsoleted by other documents at any time. It is inappropriate to cite
| this document as other than work in progress.


PointedEars
 
R

Richard Cornford

You said as well:

<quote>
I suspect that you mean; will the XML HTTP request system
automatically act on the redirection and return the response from
that
alternative source. To which the answer is that mostly they will.
</quote>

Redirecting will mostly not be attempted cross-domain.

Richard.
 
R

Richard Cornford

See the <HERE> element, ??? above ???

When you are not being understood, repeating yourself slightly louder
is a waste of everyone's time.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top