On Feb 6, 2009, at 8:53 PM, Craig McClanahan wrote:
> Paul Sandoz wrote:
>> On Feb 5, 2009, at 10:28 PM, Craig McClanahan wrote:
>>>> This looks great. I will update the sample atom+abdera
>>>> application to use this approach.
>>> OK, I just committed this change to the server application
>>> (r1949). It provides a *really* nice way to have centralized
>>> control over authentication and authorization (in a container
>>> request filter that watches all requests) coupled with annotation-
>>> based declaration of what roles are needed to allow a particular
>>> web service method to be accessed.
>>>
>>> Way cool.
>>
>> Thanks.
>>
>> From the commit i notice you are still checking the paths for the
>> "user" role.
>>
>> You don't need to his and instead you can use the username path
>> parameter i.e. inject UriInfo and use the
>> ui.getPathParameters().getFirst("username") and compare that with
>> the Principal name. This technique will work for any URI path
>> configuration that utilizes the same path parameter.
>>
> I went ahead and did this, although it has slightly different
> semantics than I had originally intended (this approach grants the
> "user" role for "/users/{username}" as well as "/contacts/
> {username}", but my @RolesAllowed settings still do what I want.
>
Oh, i did not realize that. Perhaps then two different user type roles
are required for your use-case?
> I left the other approach in as a commented out alternative, though,
> because there will likely be some applications that need to make
> more fine grained decisions based on the path segments.
OK.
Paul.