cors - Dave's Blog

Search

Windows Store App WebView Cross Origin XMLHttpRequest Behavior

2016 Jun 2, 6:45

TL;DR: Web content in a JavaScript Windows Store app or WebView in a Windows Store app that has full access to WinRT also gets to use XHR unrestricted by cross origin checks.

By default web content in a WebView control in a Windows Store App has the same sort of limitations as that web content in a web browser. However, if you give the URI of that web content full access to WinRT, then the web content also gains the ability to use XMLHttpRequest unrestricted by cross origin checks. This means no CORS checks and no OPTIONS requests. This only works if the web content's URI matches a Rule in the ApplicationContentUriRules of your app's manifest and that Rule declares WindowsRuntimeAccess="all". If it declares WinRT access as 'None' or 'AllowForWebOnly' then XHR acts as it normally does.

In terms of security, if you've already given a page access to all of WinRT which includes the HttpRequest class and other networking classes that don't perform cross origin checks, then allowing XHR to skip CORS doesn't make things worse.

PermalinkCommentsjavascript uwa uwp web webview windows winrt xhr

Retweet of annevk

2015 Mar 6, 8:02
Yay, thanks to @mastahyeti GitHub Pages now includes `Access-Control-Allow-Origin: *`! Which is totally safe: https://annevankesteren.nl/2012/12/cors-101 …
PermalinkComments

Client Side Cross Domain Data YQL Hack

2012 Feb 27, 2:28

One of the more limiting issues of writing client side script in the browser is the same origin limitations of XMLHttpRequest. The latest version of all browsers support a subset of CORS to allow servers to opt-in particular resources for cross-domain access. Since IE8 there's XDomainRequest and in all other browsers (including IE10) there's XHR L2's cross-origin request features. But the vast majority of resources out on the web do not opt-in using CORS headers and so client side only web apps like a podcast player or a feed reader aren't doable.

One hack-y way around this I've found is to use YQL as a CORS proxy. YQL applies the CORS header to all its responses and among its features it allows a caller to request an arbitrary XML, HTML, or JSON resource. So my network helper script first attempts to access a URI directly using XDomainRequest if that exists and XMLHttpRequest otherwise. If that fails it then tries to use XDR or XHR to access the URI via YQL. I wrap my URIs in the following manner, where type is either "html", "xml", or "json":

        yqlRequest = function(uri, method, type, onComplete, onError) {
var yqlUri = "http://query.yahooapis.com/v1/public/yql?q=" +
encodeURIComponent("SELECT * FROM " + type + ' where url="' + encodeURIComponent(uri) + '"');

if (type == "html") {
yqlUri += encodeURIComponent(" and xpath='/*'");
}
else if (type == "json") {
yqlUri += "&callback=&format=json";
}
...

This also means I can get JSON data itself without having to go through JSONP.
PermalinkCommentsxhr javascript yql client-side technical yahoo xdr cors

[whatwg] CORS requests for image and video elements

2011 May 23, 4:26Applying CORS to the media elements: "I've added a content attribute to <img>, <video>, and <audio> that makes the image or media resource be fetched with CORS And have the origin of the page if CORS succeeded. The attribute is "cross-origin" and it has two allowed values, "use-credentials" and "anonymous". The latter is the default, so you can just say <img cross-origin src="data.png">."PermalinkCommentscors crossdomain web browser webbrowser html technical

Comparison of CORS and UMP - Web Security

2010 May 7, 6:29UMP instead of CORS for cross-domain access control: "...a developer can read only UMP and ignore CORS, yet still create safe code. This code can successfully message with CORS resources that do not require credentials. UMP is therefore a way of messaging with the credential-free subset of CORS resources."PermalinkCommentsw3c security web browser technical
Older Entries Creative Commons License Some rights reserved.