Re: Setting CORS headers for a particular Agent

Interesting proposal! I don't know a lot about combining cors with client
certs (just found
https://connect.microsoft.com/IE/feedback/details/1028302/ie11-cors-preflight-request-is-aborted-when-server-requests-client-tls-certificate
stating it's broken in IE11).

For cookie-based systems, the usual trick is to switch to bearer tokens in
the Authorization request header (that's how we added cors to hood.ie for
instance). But for client certs you obviously don't want to do that, so a
user-supplied white-list like you propose could work, I guess.



On Sat, Feb 14, 2015 at 10:00 AM, Henry Story <henry.story@gmail.com> wrote:

> Hi all
>
> Following a Pull Request on rww-play by Sylvain Le Bon (
> https://github.com/read-write-web/rww-play/pull/133 )
> relating to the question as to how to set the CORS headers for a linked
> data server, I thought about the issue a bit,
> and came to the following conclusion. I already updated the
> WebAccessControl wiki with the following text:
> https://www.w3.org/wiki/WebAccessControl#Cors_User_Agents
>
> Here is the proposal:
>
> Setting "Access-Control-Allow-Methods" for a particular Agent
> A linked Data publisher may want to make a whole set of resources
> available over CORS. For completely publicly accessible resources that is
> reasonably easy: one can just add (please check)
>
> Access-Control-Allow-Origin: *Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
>
> In read mode that should work fine. (In write mode, one may need to be
> careful to log the user and the Origin that made the change.)
> But what should the server do for any resources that is protected? It
> cannot in a blanket manner state that the resource is accessible to every
> Origin. That would make it much too easy for a piece of JavaScript to use
> the authentication state in a browser to do whatever the designer of the JS
> wanted rather than what the browser user wanted. But if the server selects
> a particular Origin that it trusts, then that would limit the growth of
> JavaScript applications very severely to those known and trusted to the
> data publisher.
> It should really be up to browser user to specify which JavaScript it
> trusts ( sadly this can only be done with the extremely coarse Origin tool
> ). The suggestion is therefore that the user's WebID contain a list of
> trusted origins, and that the server use those to decide what Origin to add
> to the header:
>
> <#i> acl:trustedOrigin <http://apps.w3c.org/>, <http://apps.timbl.name>, </> .
>
> The server after authenticating the user, would then add those origins to
> header. If we want to allow that one trusts some origin for all read
> operations, but only some for write operations then something more complex
> would be needed such as
>
> <#i> acl:trustedOrigin [ acl:mode acl:Read;
>                          acl:agentClass foaf:Agent;                         acl:accessToClass foaf:Document;  //<- give access to all documents
>                         ],
>                         [ acl:mode acl:Write;                         acl:accessToClass foaf:Document; //<- give access to all documents
>                          acl:agent [ acl:origin <https://apps.w3.org/> ], [ acl:origin <> ]
>                         ] .
>
> The server after authenticating the user, could then use that information
> to write out what Origin is allowed what action.
>
> Any feedback?
>
> Social Web Architect
> http://bblfish.net/
>
>