Re: Accept on GET and access control - ISSUE-93

On 16 Jan 2014, at 22:00, Wilde, Erik <Erik.Wilde@emc.com> wrote:

> hello john.
> 
> On 2014-01-16, 20:32 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>> It's still valuable, for all the reasons
>> you point out.  Clients simply have a higher "probability"
>> (p=1.0) of receiving that hint from an LDP-compliant HTTP server.
> 
> just adding to that from our implementation experience: determining access
> rights can be a rather expensive operation, because it's based on
> authenticated identity, roles, and rather complicated role-based access
> models for resources. so for us, computing all access rights to all linked
> resources would result in very bad UX, because it would take a lot of time
> to complete, and the vast majority of accesses to those linked resources
> are browsing (i.e., read) only. so what we have is a way for clients to
> selectively request this kind of information, because clients know better
> what they might need. forcing servers to always compute something that
> might be expensive to compute and is not needed in probably >>99% of cases
> is not something we would be willing to do, for our specific environment.

Having coded a function to calculate this I agree that it can be potentially time consuming 
to calculate. 

[[ https://github.com/stample/rww-play/blob/master/app/rww/ldp/auth/WACAuthZ.scala#L238

 /**
   *
   * @param on   resource for which we are looking for rights
   * @param user verified WebIds of the authenticated user, or the empty list
   * @return a Future which will contain the list of wac:modes allowed: wac:Read, wac:Write, wac:Append
   */
def getAllowedMethodsForAgent(on: Rdf#URI, user: List[Rdf#URI])  : Future[Set[Rdf#URI]]
]]

Now I suppose the answer could be cached for each resource ( how feasible is that?) but I 
agree with the point that making it mandatory would mostly be wasteful of server cpu cycles, as 
in most cases the client does not need the information. For cases where the information is 
required then an OPTIONS call would return the right information.

The danger is that if we keep it as mandatory as we have it now, people might implement
the Allow header to return not what the current user can do, but what the user with the most 
rights can do ( e.g.: the Admin ). If this happens then the Allow header will be mostly a useless
hint for a client as to what types of actions he can do on the given resource. After all if Allow just
means that the user with the most rights can do something, then it gives us no information in 
addition to something being either an LDPC or  an LDPR, information which we allready have in 
the Link headers.

And the word "Allow" does suggest that the methods that are returned are those that are "allowed".
Otherwise I suppose it would have been called "Capabilities".

So my argument, and I think yours, is that if Allow is mandatory on GET, HEAD then it won't be useful
anymore due to bad implementations.

Henry

> 
> cheers,
> 
> dret.
> 
> 

Social Web Architect
http://bblfish.net/