Re: Some more questions on NSD+CORS

On Tue, Oct 8, 2013 at 1:45 AM, FABLET Youenn
<Youenn.Fablet@crf.canon.fr> wrote:
> I looked a bit more at some of the proposed changes and have some additional
> questions.
>
> Related to the requirement below:
>
> “Only Local-networked Services that pass a CORS preflight check should be
> made available to web pages by a user agent.”
>
> “Made available” is a vague term but I understand it as “the user agent
> communicates the URL of the service”, nothing more.
>
> If that is correct, why is this rule mandatory? Is it to cope with a
> security issue? to ensure a good user experience?

Both security and UX issues are covered by this check.

>
>
>
> Would it not be better if the CORS check process be abstracted a bit in the
> spec?
>
> Details as provided could be put in implementer guidelines or appendix.

The whole specification is a guide for implementers. What we actually
end up with is really just a series of testable assertions throughout
the whole specification that we can use to check implementation
completeness and interoperability. So all normative algorithms really
belong in-line in the specification and not pushed out to annexes.

>
> Browsers could for instance have the option to gather CORS information based
> on the web app origin if that works best in their environments.
>
> That would also be an encouragement for local web services implementations
> to correctly handle all preflight requests and not just the NSD ones.
>
>
>
> I can see some benefits in having CORS information when the list of services
> is presented to the user.
>
> This allows the UI to graphically differentiate (based on CORS,
> whitelisting, web app origin and privileges) the services that the web app
> will probably be able to interact with from the services it will probably
> fail.
>
> This also enables the UI to select by default only the services for which
> XHR will probably work.
>
>
>
> As of gathering of CORS information ahead of time, using the public IP
> address of the machine seems a bit odd.

I agree and I re-wrote the specification accordingly to simultaneously
remove this ambiguous origin and support full CORS in network services
(e.g. allow network services to provide access to web pages depending
on their origin).

A full diff of the changes is available at:
https://dvcs.w3.org/hg/dap/diff/140b6c8d4c18/discovery-api/Overview.src.html.

Best regards,

Rich

Received on Thursday, 10 October 2013 03:27:01 UTC