Chris,

On 11/16/2012 5:28 AM, Chris Holland wrote:
> The reason is because IE doesn't care and just does it, but Chrome will
> send an "Access-Control-Allow-Origin" header before passing the actual
> request. This header is added automatically by Chrome because it has
> detected cross site scripting.

In normal scenario (no authentication) at least I'm not seeing this at
all - neither Chrome nor Firefox send Access-Control-Allow-Origin
header. They do send the Origin header though as expected.

> I modified my web server to return a confirmation to the
>   "Access-Control-Allow-Origin" message to confirm that it was in fact
> allowed, but EWB sees some kind of response to this "allow" message that
> is not what it was expecting and throws a data response error.

I did the same and i'm seeing response code and data cleanly - no issues
with EWB. Are you using authentication and returning 401 result initally
if connection is not authenticated?


Raul

Hi Raul,

Are you sure that you are calling cross site scripting, i.e. different
IP or port address?

Chris Holland
[Team Elevate]

On 16/11/2012 15:21, Raul wrote:
> Chris,
>
> On 11/16/2012 5:28 AM, Chris Holland wrote:
>> The reason is because IE doesn't care and just does it, but Chrome will
>> send an "Access-Control-Allow-Origin" header before passing the actual
>> request. This header is added automatically by Chrome because it has
>> detected cross site scripting.
>
> In normal scenario (no authentication) at least I'm not seeing this at
> all - neither Chrome nor Firefox send Access-Control-Allow-Origin
> header. They do send the Origin header though as expected.
>
>> I modified my web server to return a confirmation to the
>>   "Access-Control-Allow-Origin" message to confirm that it was in fact
>> allowed, but EWB sees some kind of response to this "allow" message that
>> is not what it was expecting and throws a data response error.
>
> I did the same and i'm seeing response code and data cleanly - no issues
> with EWB. Are you using authentication and returning 401 result initally
> if connection is not authenticated?
>
>
> Raul
>

Raul

My EWB app is hosted on web server with IP 192.x.x.101 and EWB app
itself it calls a web service that is a delphi app running on different
machine : 192.x.x.200.

AFAIK this is classical cross site scripting.

Note that what i am seeing is as per spec (http://www.w3.org/TR/cors/) -
"Access-Control-Allow-Origin" is only needed as part of the response
headers (and not request headers - you can send it but it should be
fully ignored by the web server)

Raul

On 11/16/2012 3:48 PM, Chris Holland wrote:
> Hi Raul,
>
> Are you sure that you are calling cross site scripting, i.e. different
> IP or port address?
>
> Chris Holland
> [Team Elevate]
>
> On 16/11/2012 15:21, Raul wrote:
>> Chris,
>>
>> On 11/16/2012 5:28 AM, Chris Holland wrote:
>>> The reason is because IE doesn't care and just does it, but Chrome will
>>> send an "Access-Control-Allow-Origin" header before passing the actual
>>> request. This header is added automatically by Chrome because it has
>>> detected cross site scripting.
>>
>> In normal scenario (no authentication) at least I'm not seeing this at
>> all - neither Chrome nor Firefox send Access-Control-Allow-Origin
>> header. They do send the Origin header though as expected.
>>
>>> I modified my web server to return a confirmation to the
>>>   "Access-Control-Allow-Origin" message to confirm that it was in fact
>>> allowed, but EWB sees some kind of response to this "allow" message that
>>> is not what it was expecting and throws a data response error.
>>
>> I did the same and i'm seeing response code and data cleanly - no issues
>> with EWB. Are you using authentication and returning 401 result initally
>> if connection is not authenticated?
>>
>>
>> Raul
>>

Hi Raul,

Yes you are definately cross site scripting.

When I run my tests here using Fiddler2 to see what is being sent
between EWB (or my browser) and my WEB server I get the following:

This is what the built in browser in EWB (and IE) sends:

GET http://localhost:12009/Cypher1Users?method=rows&LoginName='1234'
HTTP/1.1
Accept: */*
X-EWBUser: Tom
X-EWBPassword: Fred
Referer: http://localhost/cypher1.html
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64;
Trident/6.0; .NET4.0E; .NET4.0C; InfoPath.3; .NET CLR 3.5.30729; .NET
CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 1.1.4322)
Host: localhost:12009
Connection: Keep-Alive

as you can see it has passed my X-EWBUser and password to the web server
as I expected.

===========================================================================

This is what chrome (and Firefox) send when making a cross site call:

OPTIONS http://localhost:12009/Cypher1Users?method=rows&LoginName='1234'
HTTP/1.1
Host: localhost:12009
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.11
(KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
Access-Control-Request-Headers: x-ewbpassword, origin, x-ewbuser
Accept: */*
Referer: http://localhost/cypher1.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

as you can see it has not passed the X-EWBUser or password, but it has
sent the "Access-Control-Request-Headers" which I believe is checking
that it is okay for this web site to perform the cross site scripting.

If I send back the correct headers to allow
"Access-Control-Request-Headers", then the browser responds with more
headers that contain the X-EWBUser and password as in the IE example above.

Chris Holland
[Team Elevate]

This is due to the custom headers i believe - in your case the browser
is doing what spec calls pre-flight to check with web service if it can
handle what it wants to do and check on credentials. In theory it could
also be due to authentication but since you're using EB custom headers i
don't think they count as authentication.

Steps are consistent still with the spec:

1. browser connects to web service with pre-flight and uses the OPTIONS
method and send :
- Access-Control-Request-Method is method it want to use againsdt web
service (GET in your case)
- Origin
- Access-Control-Request-Headers is headers it wants to send
at this point there is no body, no credentials etc sent

2. if we server is willing to accept this it should responds with 200 OK
and include
- Access-Control-Allow-Methods incldues methods it accepts (can be blank
for simple methods like GET or POST)
- Access-Control-Allow-Headers would show headers it accepts
- credentials should be true here if it wants authentication

3. if response matches what browser wants to send it will send off the
real request which is your 2nd capture below and yes you must use
Access-Control-Allow-Headers for the custom ones.

The difference with my request was that i don't do any custom headers -
my authentication is url parameter based and so it session handluign
later so i have the more basic version of this - no pre-flight needed so
straightforward request with the Origin and Access-Control-Allow-Origin
response.

Raul



On 11/19/2012 6:58 AM, Chris Holland wrote:
> Hi Raul,
>
> Yes you are definately cross site scripting.
>
> When I run my tests here using Fiddler2 to see what is being sent
> between EWB (or my browser) and my WEB server I get the following:
>
> This is what the built in browser in EWB (and IE) sends:
>
> GET http://localhost:12009/Cypher1Users?method=rows&LoginName='1234'
> HTTP/1.1
> Accept: */*
> X-EWBUser: Tom
> X-EWBPassword: Fred
> Referer: http://localhost/cypher1.html
> Accept-Language: en-GB,en;q=0.5
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64;
> Trident/6.0; .NET4.0E; .NET4.0C; InfoPath.3; .NET CLR 3.5.30729; .NET
> CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 1.1.4322)
> Host: localhost:12009
> Connection: Keep-Alive
>
> as you can see it has passed my X-EWBUser and password to the web server
> as I expected.
>
> ===========================================================================
>
> This is what chrome (and Firefox) send when making a cross site call:
>
> OPTIONS http://localhost:12009/Cypher1Users?method=rows&LoginName='1234'
> HTTP/1.1
> Host: localhost:12009
> Connection: keep-alive
> Access-Control-Request-Method: GET
> Origin: http://localhost
> User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.11
> (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
> Access-Control-Request-Headers: x-ewbpassword, origin, x-ewbuser
> Accept: */*
> Referer: http://localhost/cypher1.html
> Accept-Encoding: gzip,deflate,sdch
> Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>
> as you can see it has not passed the X-EWBUser or password, but it has
> sent the "Access-Control-Request-Headers" which I believe is checking
> that it is okay for this web site to perform the cross site scripting.
>
> If I send back the correct headers to allow
> "Access-Control-Request-Headers", then the browser responds with more
> headers that contain the X-EWBUser and password as in the IE example above.
>
> Chris Holland
> [Team Elevate]

Hi Raul,

The problem (in my case) is that after step 2 when the web server
responds with the "Access-Control-Request-Method is allowed" headers EWB
sees this somehow as the response to its request for the dataset and
fails to load the dataset with a Load Response error.

I am unsure why the browser is passing anything back to EWB just because
it receives the Access-Control-Request-Method headers.

Chris Holland
[Team Elevate]

On 19/11/2012 14:35, Raul wrote:
>
> This is due to the custom headers i believe - in your case the browser
> is doing what spec calls pre-flight to check with web service if it can
> handle what it wants to do and check on credentials. In theory it could
> also be due to authentication but since you're using EB custom headers i
> don't think they count as authentication.
>
> Steps are consistent still with the spec:
>
> 1. browser connects to web service with pre-flight and uses the OPTIONS
> method and send :
> - Access-Control-Request-Method is method it want to use againsdt web
> service (GET in your case)
> - Origin
> - Access-Control-Request-Headers is headers it wants to send
> at this point there is no body, no credentials etc sent
>
> 2. if we server is willing to accept this it should responds with 200 OK
> and include
> - Access-Control-Allow-Methods incldues methods it accepts (can be blank
> for simple methods like GET or POST)
> - Access-Control-Allow-Headers would show headers it accepts
> - credentials should be true here if it wants authentication
>
> 3. if response matches what browser wants to send it will send off the
> real request which is your 2nd capture below and yes you must use
> Access-Control-Allow-Headers for the custom ones.
>
> The difference with my request was that i don't do any custom headers -
> my authentication is url parameter based and so it session handluign
> later so i have the more basic version of this - no pre-flight needed so
> straightforward request with the Origin and Access-Control-Allow-Origin
> response.
>
> Raul
>
>
>
> On 11/19/2012 6:58 AM, Chris Holland wrote:
>> Hi Raul,
>>
>> Yes you are definately cross site scripting.
>>
>> When I run my tests here using Fiddler2 to see what is being sent
>> between EWB (or my browser) and my WEB server I get the following:
>>
>> This is what the built in browser in EWB (and IE) sends:
>>
>> GET http://localhost:12009/Cypher1Users?method=rows&LoginName='1234'
>> HTTP/1.1
>> Accept: */*
>> X-EWBUser: Tom
>> X-EWBPassword: Fred
>> Referer: http://localhost/cypher1.html
>> Accept-Language: en-GB,en;q=0.5
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64;
>> Trident/6.0; .NET4.0E; .NET4.0C; InfoPath.3; .NET CLR 3.5.30729; .NET
>> CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 1.1.4322)
>> Host: localhost:12009
>> Connection: Keep-Alive
>>
>> as you can see it has passed my X-EWBUser and password to the web server
>> as I expected.
>>
>> ===========================================================================
>>
>>
>> This is what chrome (and Firefox) send when making a cross site call:
>>
>> OPTIONS http://localhost:12009/Cypher1Users?method=rows&LoginName='1234'
>> HTTP/1.1
>> Host: localhost:12009
>> Connection: keep-alive
>> Access-Control-Request-Method: GET
>> Origin: http://localhost
>> User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.11
>> (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
>> Access-Control-Request-Headers: x-ewbpassword, origin, x-ewbuser
>> Accept: */*
>> Referer: http://localhost/cypher1.html
>> Accept-Encoding: gzip,deflate,sdch
>> Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>>
>> as you can see it has not passed the X-EWBUser or password, but it has
>> sent the "Access-Control-Request-Headers" which I believe is checking
>> that it is okay for this web site to perform the cross site scripting.
>>
>> If I send back the correct headers to allow
>> "Access-Control-Request-Headers", then the browser responds with more
>> headers that contain the X-EWBUser and password as in the IE example
>> above.
>>
>> Chris Holland
>> [Team Elevate]
>

Chris,

<< I am unsure why the browser is passing anything back to EWB just because
it receives the Access-Control-Request-Method headers. >>

This is the part that I'm unsure about also, but I'll see if I can replicate
the issue and come up with a workaround.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

That would be fantastic if you could.

Many thanks.

Chris Holland
[Team Elevate]

On 03/12/2012 20:33, Tim Young [Elevate Software] wrote:
> Chris,
>
> << I am unsure why the browser is passing anything back to EWB just
> because it receives the Access-Control-Request-Method headers. >>
>
> This is the part that I'm unsure about also, but I'll see if I can
> replicate the issue and come up with a workaround.
>
> Thanks,
>
> Tim Young
> Elevate Software
> www.elevatesoft.com

Hi Tim,

Did you get a chance to look at why this is happening yet?

Chris Holland
[Team Elevate]

On 03/12/2012 20:33, Tim Young [Elevate Software] wrote:
> Chris,
>
> << I am unsure why the browser is passing anything back to EWB just
> because it receives the Access-Control-Request-Method headers. >>
>
> This is the part that I'm unsure about also, but I'll see if I can
> replicate the issue and come up with a workaround.
>
> Thanks,
>
> Tim Young
> Elevate Software
> www.elevatesoft.com

Chris,

<< Did you get a chance to look at why this is happening yet? >>

Don't read the release notes, huh ?

1.01 B3 had new support for CORS (cross-origin resource sharing) in the EWB
web server.  More information here:

http://www.elevatesoft.com/manual?action=viewtopic&id=ewb1&topic=Configuring_Server

under "Content".

Make sure that the "Enable Cross-Origin Resource Sharing" check box is
checked, and you'll then be able to have the EWB web server serve up dataset
content for an application loaded using a different URL/web server.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com