Re: CSP ignored when using remote content
Guuuys! Thanks for your answers and all! But i guess i haven't been clear enough, i already know it works on file:///, I want it to work when its nt file:/// but a remte source! And whats this talk about CORS headers? You can make XHRs to ANYTHING when using a local cordova content src (file:///), the server doesnt need to send ANY CORS headers! Try it. But i want to use a remoote source, NOT file:///. So something like content src=http://remoteserver.com/app/index.html;. And no the server doesnt send me CORS headers, i need it to work without CORS headers, like it does with the file:/// already! Whats happening in my case? I get a regular chrome same-origin-policy message No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'remoteserver.com' is therefore not allowed access.. THIS DOES NOT HAPPEN WHEN I RUN THE EXACT SAME APP/HTML/JAVASCRIPT FROM A LOCAL CONTENT SRC. SO WHY DOESNT IT WHEN USING A REMOTE SRC? Is it intentional? Is that how cordova is supposed to work? Why the discrepancy? Is it a bug? Im not trying to be disrespectful, i have great respect for you guys. I just want to make myself understood clearly now, so that you understand my question 100%. On 22 May 2015 at 21:08, Shazron shaz...@gmail.com wrote: If using the wkwebview-engine plugin in cordova-ios 4.0 (release TBD), using file:/// URLs will respect CORS, I believe (Device: you can only test this currently with files loaded from the tmp folder: https://github.com/shazron/WKWebViewFIleUrlTest - Simulator: anything goes) The wkwebview-engine plugin uses the new WKWebView component in iOS 8, instead of the system UIWebView (which doesn't care about CORS). I haven't tested this with the latest iOS 8.3 though. On Fri, May 22, 2015 at 11:42 AM, Nikhil Khandelwal nikhi...@microsoft.com wrote: CORS does not apply for local content using file:///, hence, browser will allow all XHRs when your origin is local. When you host content on remoteserver.com CORS is applied. If you make an XHR to xhr.com, the browser will pre-flight a request to xhr.com asking if xhr.com supports xhr access from remoteserver.com. xhr.com responds using a response header - 'Access-Control-Allow-Origin' allowing XHR to be allowed or not. You can use network inspection tools to see the request/response to see what's happening in your case and understand the failure. Thanks, Nikhil -Original Message- From: Pär [mailto:p.majh...@gmail.com] Sent: Thursday, May 21, 2015 6:24 PM To: dev@cordova.apache.org Subject: Re: CSP ignored when using remote content Thanks for the reply. Yes, the CSP rules are defined by the page that is loaded, wherever that is. The thing is that the behavior when loading that page from a remote server is different from the behavior when loading the page locally, even though its the exact same page. I have access origin=* and CSP default-src *. When i have a local content src i can do any cross origin XHR's. Then i change content src to a server where i serve the platform/www folder of my cordova project, and suddently the same XHR's are blocked. So the behaviour is different just from one varialbe changning; content src. On 22 May 2015 at 02:27, Jesse purplecabb...@gmail.com wrote: This is the intended behavior. The csp rules are defined by the page that is loaded, wherever it is. Pointing content.src to a remote server basically means, ignore anything that is in www/index.html. @purplecabbage risingj.com On Thu, May 21, 2015 at 2:16 PM, Pär p.majh...@gmail.com wrote: When using a remote content src like content src= http://remoteserver.com/app/index.html; the CSP rules seems to be ignored; cross origin requests fail even with a default-src * CSP. Is this intended behaviour or a bug? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: CSP ignored when using remote content
As they have told you and you already know, CORS doesn't apply when you load from file, but it apply when you load from http, if you change the content src to and http page then CORS apply, you can't make it work from remote servers, it's not a cordova thing, it's a webview thing El sábado, 23 de mayo de 2015, Pär p.majh...@gmail.com escribió: Guuuys! Thanks for your answers and all! But i guess i haven't been clear enough, i already know it works on file:///, I want it to work when its nt file:/// but a remte source! And whats this talk about CORS headers? You can make XHRs to ANYTHING when using a local cordova content src (file:///), the server doesnt need to send ANY CORS headers! Try it. But i want to use a remoote source, NOT file:///. So something like content src=http://remoteserver.com/app/index.html;. And no the server doesnt send me CORS headers, i need it to work without CORS headers, like it does with the file:/// already! Whats happening in my case? I get a regular chrome same-origin-policy message No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'remoteserver.com' is therefore not allowed access.. THIS DOES NOT HAPPEN WHEN I RUN THE EXACT SAME APP/HTML/JAVASCRIPT FROM A LOCAL CONTENT SRC. SO WHY DOESNT IT WHEN USING A REMOTE SRC? Is it intentional? Is that how cordova is supposed to work? Why the discrepancy? Is it a bug? Im not trying to be disrespectful, i have great respect for you guys. I just want to make myself understood clearly now, so that you understand my question 100%. On 22 May 2015 at 21:08, Shazron shaz...@gmail.com javascript:; wrote: If using the wkwebview-engine plugin in cordova-ios 4.0 (release TBD), using file:/// URLs will respect CORS, I believe (Device: you can only test this currently with files loaded from the tmp folder: https://github.com/shazron/WKWebViewFIleUrlTest - Simulator: anything goes) The wkwebview-engine plugin uses the new WKWebView component in iOS 8, instead of the system UIWebView (which doesn't care about CORS). I haven't tested this with the latest iOS 8.3 though. On Fri, May 22, 2015 at 11:42 AM, Nikhil Khandelwal nikhi...@microsoft.com javascript:; wrote: CORS does not apply for local content using file:///, hence, browser will allow all XHRs when your origin is local. When you host content on remoteserver.com CORS is applied. If you make an XHR to xhr.com, the browser will pre-flight a request to xhr.com asking if xhr.com supports xhr access from remoteserver.com. xhr.com responds using a response header - 'Access-Control-Allow-Origin' allowing XHR to be allowed or not. You can use network inspection tools to see the request/response to see what's happening in your case and understand the failure. Thanks, Nikhil -Original Message- From: Pär [mailto:p.majh...@gmail.com javascript:;] Sent: Thursday, May 21, 2015 6:24 PM To: dev@cordova.apache.org javascript:; Subject: Re: CSP ignored when using remote content Thanks for the reply. Yes, the CSP rules are defined by the page that is loaded, wherever that is. The thing is that the behavior when loading that page from a remote server is different from the behavior when loading the page locally, even though its the exact same page. I have access origin=* and CSP default-src *. When i have a local content src i can do any cross origin XHR's. Then i change content src to a server where i serve the platform/www folder of my cordova project, and suddently the same XHR's are blocked. So the behaviour is different just from one varialbe changning; content src. On 22 May 2015 at 02:27, Jesse purplecabb...@gmail.com javascript:; wrote: This is the intended behavior. The csp rules are defined by the page that is loaded, wherever it is. Pointing content.src to a remote server basically means, ignore anything that is in www/index.html. @purplecabbage risingj.com On Thu, May 21, 2015 at 2:16 PM, Pär p.majh...@gmail.com javascript:; wrote: When using a remote content src like content src= http://remoteserver.com/app/index.html; the CSP rules seems to be ignored; cross origin requests fail even with a default-src * CSP. Is this intended behaviour or a bug? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org javascript:; For additional commands, e-mail: dev-h...@cordova.apache.org javascript:;
Re: CSP ignored when using remote content
Oh, so its a webview thing. I see. Thanks for that straight forward answer. As they have told you and you already know, CORS doesn't apply when you load from file, but it apply when you load from http, if you change the content src to and http page then CORS apply, you can't make it work from remote servers, it's not a cordova thing, it's a webview thing El sábado, 23 de mayo de 2015, Pär p.majh...@gmail.com escribió: Guuuys! Thanks for your answers and all! But i guess i haven't been clear enough, i already know it works on file:///, I want it to work when its nt file:/// but a remte source! And whats this talk about CORS headers? You can make XHRs to ANYTHING when using a local cordova content src (file:///), the server doesnt need to send ANY CORS headers! Try it. But i want to use a remoote source, NOT file:///. So something like content src=http://remoteserver.com/app/index.html;. And no the server doesnt send me CORS headers, i need it to work without CORS headers, like it does with the file:/// already! Whats happening in my case? I get a regular chrome same-origin-policy message No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'remoteserver.com' is therefore not allowed access.. THIS DOES NOT HAPPEN WHEN I RUN THE EXACT SAME APP/HTML/JAVASCRIPT FROM A LOCAL CONTENT SRC. SO WHY DOESNT IT WHEN USING A REMOTE SRC? Is it intentional? Is that how cordova is supposed to work? Why the discrepancy? Is it a bug? Im not trying to be disrespectful, i have great respect for you guys. I just want to make myself understood clearly now, so that you understand my question 100%. On 22 May 2015 at 21:08, Shazron shaz...@gmail.com javascript:; wrote: If using the wkwebview-engine plugin in cordova-ios 4.0 (release TBD), using file:/// URLs will respect CORS, I believe (Device: you can only test this currently with files loaded from the tmp folder: https://github.com/shazron/WKWebViewFIleUrlTest - Simulator: anything goes) The wkwebview-engine plugin uses the new WKWebView component in iOS 8, instead of the system UIWebView (which doesn't care about CORS). I haven't tested this with the latest iOS 8.3 though. On Fri, May 22, 2015 at 11:42 AM, Nikhil Khandelwal nikhi...@microsoft.com javascript:; wrote: CORS does not apply for local content using file:///, hence, browser will allow all XHRs when your origin is local. When you host content on remoteserver.com CORS is applied. If you make an XHR to xhr.com, the browser will pre-flight a request to xhr.com asking if xhr.com supports xhr access from remoteserver.com. xhr.com responds using a response header - 'Access-Control-Allow-Origin' allowing XHR to be allowed or not. You can use network inspection tools to see the request/response to see what's happening in your case and understand the failure. Thanks, Nikhil -Original Message- From: Pär [mailto:p.majh...@gmail.com javascript:;] Sent: Thursday, May 21, 2015 6:24 PM To: dev@cordova.apache.org javascript:; Subject: Re: CSP ignored when using remote content Thanks for the reply. Yes, the CSP rules are defined by the page that is loaded, wherever that is. The thing is that the behavior when loading that page from a remote server is different from the behavior when loading the page locally, even though its the exact same page. I have access origin=* and CSP default-src *. When i have a local content src i can do any cross origin XHR's. Then i change content src to a server where i serve the platform/www folder of my cordova project, and suddently the same XHR's are blocked. So the behaviour is different just from one varialbe changning; content src. On 22 May 2015 at 02:27, Jesse purplecabb...@gmail.com javascript:; wrote: This is the intended behavior. The csp rules are defined by the page that is loaded, wherever it is. Pointing content.src to a remote server basically means, ignore anything that is in www/index.html. @purplecabbage risingj.com On Thu, May 21, 2015 at 2:16 PM, Pär p.majh...@gmail.com javascript:; wrote: When using a remote content src like content src= http://remoteserver.com/app/index.html; the CSP rules seems to be ignored; cross origin requests fail even with a default-src * CSP. Is this intended behaviour or a bug? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org javascript:; For additional commands, e-mail: dev-h...@cordova.apache.org javascript:;
RE: CSP ignored when using remote content
CORS does not apply for local content using file:///, hence, browser will allow all XHRs when your origin is local. When you host content on remoteserver.com CORS is applied. If you make an XHR to xhr.com, the browser will pre-flight a request to xhr.com asking if xhr.com supports xhr access from remoteserver.com. xhr.com responds using a response header - 'Access-Control-Allow-Origin' allowing XHR to be allowed or not. You can use network inspection tools to see the request/response to see what's happening in your case and understand the failure. Thanks, Nikhil -Original Message- From: Pär [mailto:p.majh...@gmail.com] Sent: Thursday, May 21, 2015 6:24 PM To: dev@cordova.apache.org Subject: Re: CSP ignored when using remote content Thanks for the reply. Yes, the CSP rules are defined by the page that is loaded, wherever that is. The thing is that the behavior when loading that page from a remote server is different from the behavior when loading the page locally, even though its the exact same page. I have access origin=* and CSP default-src *. When i have a local content src i can do any cross origin XHR's. Then i change content src to a server where i serve the platform/www folder of my cordova project, and suddently the same XHR's are blocked. So the behaviour is different just from one varialbe changning; content src. On 22 May 2015 at 02:27, Jesse purplecabb...@gmail.com wrote: This is the intended behavior. The csp rules are defined by the page that is loaded, wherever it is. Pointing content.src to a remote server basically means, ignore anything that is in www/index.html. @purplecabbage risingj.com On Thu, May 21, 2015 at 2:16 PM, Pär p.majh...@gmail.com wrote: When using a remote content src like content src= http://remoteserver.com/app/index.html; the CSP rules seems to be ignored; cross origin requests fail even with a default-src * CSP. Is this intended behaviour or a bug?
Re: CSP ignored when using remote content
This is the intended behavior. The csp rules are defined by the page that is loaded, wherever it is. Pointing content.src to a remote server basically means, ignore anything that is in www/index.html. @purplecabbage risingj.com On Thu, May 21, 2015 at 2:16 PM, Pär p.majh...@gmail.com wrote: When using a remote content src like content src= http://remoteserver.com/app/index.html; the CSP rules seems to be ignored; cross origin requests fail even with a default-src * CSP. Is this intended behaviour or a bug?
Re: CSP ignored when using remote content
Thanks for the reply. Yes, the CSP rules are defined by the page that is loaded, wherever that is. The thing is that the behavior when loading that page from a remote server is different from the behavior when loading the page locally, even though its the exact same page. I have access origin=* and CSP default-src *. When i have a local content src i can do any cross origin XHR's. Then i change content src to a server where i serve the platform/www folder of my cordova project, and suddently the same XHR's are blocked. So the behaviour is different just from one varialbe changning; content src. On 22 May 2015 at 02:27, Jesse purplecabb...@gmail.com wrote: This is the intended behavior. The csp rules are defined by the page that is loaded, wherever it is. Pointing content.src to a remote server basically means, ignore anything that is in www/index.html. @purplecabbage risingj.com On Thu, May 21, 2015 at 2:16 PM, Pär p.majh...@gmail.com wrote: When using a remote content src like content src= http://remoteserver.com/app/index.html; the CSP rules seems to be ignored; cross origin requests fail even with a default-src * CSP. Is this intended behaviour or a bug?
