- From: Ming Jin <ming.jin.web@gmail.com>
- Date: Fri, 29 Mar 2013 00:34:42 +0900
- To: "SULLIVAN, BRYAN L" <bs3131@att.com>
- Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>
- Message-ID: <CAHNuU=u36cXp2GXc9jbJZsLTxPxhZ9CvjDe9YRmnNRq+_t0B0A@mail.gmail.com>
2013/3/27 SULLIVAN, BRYAN L <bs3131@att.com> > I think CORS should work as is, since the origin header will be set > correctly by the web runtime (browser or native web engine) and the > resource (network based or local server) can choose to honor the request or > not. > > 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. 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). This means that if we allow CORS as is for packaged apps, there'll be no way to do any XHR call from a packaged app. 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. Regards, Ming Jin
Received on Thursday, 28 March 2013 15:35:13 UTC