HATEOAS Patch

Devan Goodwin dgoodwin at rm-rf.ca
Fri Aug 27 14:24:54 UTC 2010


On Wed, Aug 25, 2010 at 1:15 PM, Devan Goodwin <dgoodwin at rm-rf.ca> wrote:
>>> Does this list need to get filtered depending on whether or not your
>>> current role has access to those calls? For instance, only a super
>>> admin can list the owners.
>>
>> Yeah this seems like the right thing to do.  IMHO it is poor user design
>> to present options that are not available.
>
> Ok thought so, I will try to make it happen.
>

So how badly do we want this list of links filtered based on permissions?

I'm seeing a problem with REST and our model here. Let's say my top
level links comes back with /pools, and I'm authenticating as a
consumer.

Clearly I can GET /pools and view the pools I have access too. Now
with REST, it's implicit that you know the methods you can run on a
resource right? But in this case, a consumer cannot POST to /pools,
whereas a super admin could. Am I correct that this information is not
represented anywhere in HATEOAS, we just have to give back the links
and accept that some operations will fail on them if you try, whereas
others will succeed. (similarly for some that are not implemented)

With this in mind,  I got to thinking it may not be worth filtering
the top level links because the security on the operations beneath
them are not going to be accurately represented anyhow.

Even for the top level, filtering will be somewhat difficult. In the
root resource, we'll need to do *heavy* introspection on the Resource
classes to determine what links should appear. Basically we have to
hard code a list of the Resource classes, examine the @Path on those
to extract just the name of the objects. If we now want to check the
security, we have to run through that class and find a method with
@GET and no @Path, possibly with some other checks as well. (quite
messy) The alternative would be just hard coding the security logic in
the root resource that builds the links, but then it's duplicated with
the real security on the method in the Resource class, and undoubtedly
will get out of sync.

Thoughts?

Thanks,

Devan


-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca



More information about the candlepin mailing list