Re: [discovery-api] CORS support added to NSD API Editor's Draft

On Wed, Oct 9, 2013 at 2:41 AM,  <Cathy.Chan@nokia.com> wrote:
>
>> -----Original Message-----
>> From: ext Rich Tibbett [mailto:richt@opera.com]
>> Sent: Tuesday, October 08, 2013 1:13 AM
>> To: Chan Cathy (Nokia-CIC/Boston)
>> Cc: Tatsuya.Igarashi@jp.sony.com; FABLET Youenn; Device APIs Working
>> Group
>> Subject: Re: [discovery-api] CORS support added to NSD API Editor's Draft
>>
>> On Tue, Oct 8, 2013 at 8:49 AM,  <Cathy.Chan@nokia.com> wrote:
>> >
>> >> -----Original Message-----
>> >> From: ext Igarashi, Tatsuya [mailto:Tatsuya.Igarashi@jp.sony.com]
>> >> Sent: Monday, October 07, 2013 8:41 AM
>> >> To: Rich Tibbett; FABLET Youenn
>> >> Cc: Device APIs Working Group
>> >> Subject: RE: [discovery-api] CORS support added to NSD API Editor's
>> >> Draft
>> >>
>> >> About the source origin value of pre-flight, the empty should be used
>> >> just to determine if the device support CORS.
>> >
>> > Agreed that the primary purpose of the preflight request should be to
>> determine if CORS is supported. As a bonus, if the result comes back as a
>> wild-card, the UA knows that any web app would be allowed to talk to that
>> service (upon user permission).
>> >
>> > But using an empty origin might cause the UA to incorrectly interpret a
>> server that supports CORS but allows only a specific list of origins as not
>> supporting CORS. An alternative is to use the target service's own origin
>> instead in the preflight request. The result would be one of the following:
>> > 1. The request fails -> the target service does not support CORS. In this case,
>> the UA must not include this service in its list of services.
>> > 2. The request succeeds with "Access-Control-Allow-Origin: *" -> the target
>> service supports CORS and accepts requests from any origin. In this case, the
>> UA includes this service in its list of services. The service will be presented to
>> the user as is.
>> > 3. The request succeeds with "Access-Control-Allow-Origin: target service's
>> origin" -> the target service supports CORS but only accepts requests from
>> certain origins (such as its own). In this case, the UA still records this service in
>> its list of services, but marks it as "conditional".
>>
>> Yes, this is exactly how it should work.
>>
>> I'm still not sure exactly what source origin should be used. At this point of
>> the algorithm we are only interested in what the cross-origin response
>> headers say rather than ensuring a match to the preflight request's origin so
>> largely it shouldn't matter what we set the source origin as.
>>
> If I understand correctly, the Access-Control-Allow-Origin response header contains either a single origin (the one that was in the request) or '*'. It does not return the entire list of allowed origins, which can potentially be extremely long. I'd be happy to be corrected as it would make our life easier here.
>
> Using an empty string as the origin in the preflight request (is that even allowed?) would result in either a failed request or a success with '*' as the allowed origin. There would be no way for the server to indicate that it supports CORS but only for some origins. (It would not (could not?) return 'Access-Control-Allow-Origin: [empty]' - it doesn't even make semantic sense.)
>
> I made the assumption here that a properly configured server that supports CORS would allow access from its own origin, hence the use of the service's own origin in the preflight request. Unfortunately it's not foolproof as it is possible that a poorly configured service might have left out its own origin in its list of allowed origins. But it still has a better chance of detecting servers that support CORS with a specific list of allowed origins than using any other origin, including the public IP address of the current machine.

I have rewritten most of the CORS-related aspects in the NSD
specification to resolve these issues. It is much easier and more
reliable to only do CORS checks when we know the origin of a
particular requesting script (i.e. when getNetworkServices() is
invoked). This also gives network services the ability to provide
access to certain origins only instead of always needing to provide a
wildcard ('*') matcher. That was also requested in previous messages
on this thread.

I also removed the term and cross-spec references to 'preflight' from
the spec. There is no 'flight' that occurs immediately after the
'preflight' in our usage of CORS here so it would be better to
describe our CORS check process as a 'preliminary' check rather than a
'preflight' check. So now we define this all as the 'preliminary CORS
check' in the spec.

A full diff is available at
https://dvcs.w3.org/hg/dap/diff/140b6c8d4c18/discovery-api/Overview.src.html.
The latest editor's draft version of the NSD API spec is at
https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html.

Many thanks to Cathy, Youenn and Igarashi-san for their input on this thread.

br/ Rich

Received on Thursday, 10 October 2013 03:25:46 UTC