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

On 29 Jan 2014, at 15:15, Steve Speicher <sspeiche@gmail.com> wrote:

> 
> On Tue, Jan 28, 2014 at 8:16 AM, Henry Story <henry.story@bblfish.net> wrote:
> 
> 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.
> 
> 
> I think it is hard to call an implementation attempting to be fast/efficient a bad implementation.  

Of course. If it is fast, efficient and correct then everything is fine.  :-)
The problem is for those cases where for the sake of efficiency correctness is sacrificed.
correctness is defined by:
[[ 
 The actual set of allowed methods is defined by the origin server at the time of each request. 
]]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7


> I would suggest that we leave spec as-is and include some of these points to help guide implementations in our Guidelines and Best Practices document.  Stating that servers should make every attempt to provide the most accurate tokens in the Allow header based on all the information it has, including client creds, but server implementations will have obvious tradeoffs to consider regarding response time.  There is also a time window problem, between the client receiving the accurate response in a Allow header and then by the time the client formulates and sends the request.  The conditions on the server may have changed to not allow that verb anymore, and the client has to deal with these responses anyway (regardless how truthful the OPTIONS are).  Of course, the better the implementation is at providing accurate Allow responses, the fewer gaps there will be when a client attempts the verbs.  I would imagine that end-users of applications that have these problems would favor ones with more accurate responses (not just Allow), so it feels more like best practices at this point.

I think all that is a very good idea.

But it is true that it does not address Erik Wilde's issue about it being very likely that most requests will never
need this information and that it is expensive to calculate, so that perhaps making the information obligatory
in GET or HEAD is likely to lead to bad practices.



> 
> - Steve
>  
> Henry
> 
>> 
>> cheers,
>> 
>> dret.
>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/