Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General Discussion » View Thread |
Messages 11 to 20 of 20 total |
How call a webserver from same host |
Fri, Nov 16 2012 10:21 AM | Permanent Link |
Raul Team Elevate | 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 |
Fri, Nov 16 2012 3:48 PM | Permanent Link |
Chris Holland SEC Solutions Ltd. Team Elevate | 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 > |
Sun, Nov 18 2012 6:15 PM | Permanent Link |
Raul Team Elevate | 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 >> |
Mon, Nov 19 2012 6:58 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. Team Elevate | 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] |
Mon, Nov 19 2012 9:35 AM | Permanent Link |
Raul 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] |
Tue, Nov 20 2012 3:33 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. 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] > |
Mon, Dec 3 2012 3:33 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Dec 4 2012 3:36 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. Team Elevate | 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 |
Thu, Jan 10 2013 2:59 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. Team Elevate | 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 |
Thu, Jan 10 2013 7:02 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |