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

I can foresee scenarios where service access is limited to specific domains.
Maintenance/monitoring services may only be made accessible to scripts from device manufacturer domains.
Companies that rent devices (e.g. ADSL boxes/set top boxes) may also like to restrict XHR calls to HTTPS domains they own.

The NSD API should at least provide the same functionality as a user that directly gives the URL of a local service to a web page.
The above use-cases would work with the user inputting approach.
They should also be supported through the NSD API.

Thanks,
 youenn


> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: lundi 7 octobre 2013 10:53
> To: FABLET Youenn
> Cc: Device APIs Working Group
> Subject: Re: [discovery-api] CORS support added to NSD API Editor's Draft
> 
> Hi Youenn,
> 
> On Mon, Oct 7, 2013 at 7:34 PM, FABLET Youenn
> <Youenn.Fablet@crf.canon.fr> wrote:
> > Two questions after scheming through the CORS preflight check:
> > 1. Why setting the source origin to the public IP address of the current
> machine and not to the script origin?
> 
> It is because the timing of service discovery can occur in the background and
> therefore a CORS preflight check as defined in the spec would not have a
> specific script origin at that time.
> 
> The reason public IP address of the current machine is used is because it is
> highly unlikely that a network service will provide access to specific hosts in
> what is a highly dynamic, NAT-based home environment. Therefore, the
> choice of source origin selection is actually intentionally arbitrary. What we
> are really looking for is wildcard CORS support i.e. 'Access-Control-Allow-
> Origin: *'. That therefore doesn't really allow for granular CORS support in
> network services but is a trade-off with the flexibility available to
> implementers in service discovery mechanism timing. Perhaps it depends on
> which consideration is more important to have (flexible network discovery
> timing or granular CORS support for services).
> 
> >
> > 2. Which HTTP methods should actually be checked in advance? GET only?
> POST? More?
> > Depending on the particular service implementation of CORS, this initial
> check may not always be sufficient.
> > Web apps may anyway need to discover what is authorized by itself.
> 
> It would be the default method, GET, that is checked since this method is the
> most likely to succeed. The response would contain all the HTTP methods on
> which CORS is enabled (in the 'Access-Control-Allow-Methods' response
> header). That is the current design given the implied constraints of checking
> for CORS support without knowing all of the method(s) required during
> service interaction up-front.
> 
> Best regards,
> 
> Rich

Received on Monday, 7 October 2013 14:14:59 UTC