Re: Setting CORS headers for a particular Agent

Sent from my iPad

> On 15 Feb 2015, at 3:06 am, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
>> On 2/14/15 4:00 AM, Henry Story 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 [ acl:origin "*" ]
>>                         ],
>>                         [ acl:mode acl:Write;
>>                          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.
>> 
> 
> Neat idea. 
> 
> I like that fact that is boils down to:
> 
> 1. Ontology tweak
> 2. New relation in WebID-Profile doc.
> 
> This is the practical way to inject smarter solutions into the Web :) 
> 
+1
> -- 
> Regards,
> 
> Kingsley Idehen	      
> Founder & CEO 
> OpenLink Software     
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this