- From: Janusz Majnert <jmajnert@gmail.com>
- Date: Mon, 8 Apr 2013 16:11:59 -0400
- To: Robin Berjon <robin@w3.org>
- Cc: Janusz Majnert <j.majnert@samsung.com>, public-sysapps@w3.org
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. If the provider of the API is not CORS enabled or is CORS enabled but is not aware of the new "app" scheme, then there is no simple way the packaged app could use the API. And that's the scenario we are discussing. I agree that if: - the "app" scheme becomes recognised as valid for the wider public - we make the authority part of the packaged application origin uniquely identify the application then there will be no problem for the API provider to properly configure their servers. /Janusz
Received on Monday, 8 April 2013 20:12:26 UTC