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

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

- Steve


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