- From: Robin Berjon <robin@w3.org>
- Date: Tue, 02 Apr 2013 12:58:11 +0200
- To: Ming Jin <ming.jin.web@gmail.com>
- CC: "SULLIVAN, BRYAN L" <bs3131@att.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Hi Ming Jin! On 28/03/2013 16:34 , Ming Jin wrote: > IMHO, compared to hosted apps (or browser-based apps, as you call it), > there are a few things that packaged apps (local resources) are not > quite appropriate for CORS. > > First thing is the uniqueness of "app://" based origin. Unlike DNS that > has a central authority (IANA) to ensure the uniqueness of an internet > domain, there's no such authority for "app://<opaque_string>" origin. If > we cannot ensure global uniqueness, by theory it's not reliable to > implement access control logic based on "app://" origin on the server-side. We can ensure (reasonable) global uniqueness for apps if we use an app:// scheme. There are several options. One is to use a GUID or something like that, which is reasonably unique. The downside to that it's not very helpful for sites that might wish to use CORS selectively (i.e. not to use "*" but rather reply with a specific host) since the GUID is, by nature, different for every installation. Another option is to use something like a hash of the manifest or of the content (whatever smallest unit we have that isn't easily forgeable) as the authority part in the app URI, e.g. app://deadb33f/. This means that an app's authority changes with updates (which probably isn't a problem) but more importantly it means that if it sends a CORS request with Origin: app://deadb33f/ the server can identify the origin and take that into account in its response. > Second is that, unlike hosted apps which can at least make XHR calls to > the same origin, every XHR call in a packaged app is cross-origin (i.e., > no same-origin XHR at all). Actually, I really think that packaged apps should be able to make same-origin XHR requests. To begin with is the potential ability to be granted an origin (as discussed in my reply to Jonas) but ever without that an app should be able to make XHR requests to the contents of the package. (We should learn from the widgets effort here and not wait to properly define access to package. I think that describing it in NavCon terms would be helpful.) > Third point is that there will be no http cookies or authentication info > generated upon loading a local resource file from a packaged app. That > said XHR calls with "withCredentials" flag set "true" will not be able > to send any cookies or auth info. With NavigationController there could be :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 2 April 2013 10:58:25 UTC