Re: Setting CORS headers for a particular Agent

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.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/  <http://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 :)

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