- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 10 Apr 2013 01:00:18 +0200
- To: Janusz Majnert <jmajnert@gmail.com>
- Cc: Robin Berjon <robin@w3.org>, Janusz Majnert <j.majnert@samsung.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
On Mon, Apr 8, 2013 at 10:11 PM, Janusz Majnert <jmajnert@gmail.com> wrote: > Hi Robin, > >>> I think we have a perfectly good solution now: CSP + CORS. The problem, >>> as Ming Jin stated in the first message, is that most servers are not >>> yet CORS enabled, and even if they are, they will not recognise the >>> "app://" origins of packaged apps. To make matters worse, we still don't >>> know how the origin will be constructed, will it identify the application. >> >> >> I'm sorry, but I'm not sure I understand the limitations that you're seeing >> here. >> >> In my experience, CORS-enabling a server, at least for the simple cases that >> don't require a preflight, is actually fairly simple. Doubly so if you >> consider that in most cases you want to access an API of some form, which >> means that the required headers are under programmatic control and therefore >> relatively easily changed. Sure enough, CORS-exposing static files on a >> shared server, or coding up preflight checks, can be hard, but I think those >> are closer to corner cases. >> >> As for recognising app: origins I'm not sure what the problem is. We can >> make the app: authority predictable for a given application if we need to. >> Beyond that, I don't see what's special about app: that would be a problem >> to servers. > > We are talking about packaged apps that want to use someone else's > APIs. Actually, I was mostly talking about a developer wanting to develop a packaged app that wants to use the developers *own* APIs. I.e. a developer writing a packaged app, as well as a server which provides various APIs that the packaged app is intended to use. / Jonas
Received on Tuesday, 9 April 2013 23:01:16 UTC