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



> -----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.

- Cathy.

> > Upon receiving a getNetworkServices request from a web page (where this
> service matches a requested type), the UA issues another preflight request
> with the web page's origin to determine whether that web page would be
> allowed access, and use the result to decide whether the service can be
> presented to the user. The UA may also store this information for future use
> (until expiration).
> 
> Wasn't that allowed origin already provided in the original preflight check
> 'Access-Control-Allow-Origin' response header? In that case we may not
> need to perform another preflight check before presenting this service to
> the user when getNetworkServices() is called from script running on this
> allowed origin.
> 
> I will update the spec accordingly.
> 
> br/ Rich

Received on Tuesday, 8 October 2013 15:46:44 UTC