Paul Sandoz wrote:
>
> On Feb 2, 2009, at 8:45 PM, Craig McClanahan wrote:
>
>> Paul Sandoz wrote:
>>> If you want this to be part of the 1.0.2 then it needs to be done
>>> within the next three days as i would prefer to freeze features by
>>> COB Wednesday,
>>>
>> I've just returned to the US from a Europe trip, and have a couple
>> things on my plate that I will target to finish by this time (thanks
>> to Paul for getProviders in the client API):
>>
>> * Investigate the problem with truncated file uploads reported in the
>> user mailing list last week, fix jersey-multipart as needed.
>>
>> * Simple example for jersey-atom-abdera based on the existing
>> jersey-atom-server sample app.
>>
>
> Thank for committing the atom samples. Great documentation!
>
You're welcome.
> At first i did wonder if it would make sense to combine into one
> sample but after i read the documentation it makes a lot of sense as is.
>
I have found this pattern very useful in the "day job" way that I'm
using Jersey.
> I see the authorization/authentication code.
>
> The latter is just right for a new feature i added: resource specific
> filters. This way you do not need to look at the path. See the class:
>
> com.sun.jersey.api.container.filter.RolesAllowedResourceFilterFactory
>
> that works for @RolesAllowed.
>
You're right ... this would be a great fit. Can you tell I wrote this
code before resource specific filters existed? :-)
> It would be nice if we could connect this to the SecurityContext and
> Principle. We should be able to override the behavior of the current
> SecurityContext injection and inject our own implementation. Then it
> would work with @RolesAllowed.
>
That's a good idea as well. A lot of people should be able to find this
authZ/authN example useful, even if they don't care about the Atom part.
> As for the client side we have two options:
>
> 1) Use a client filter for the auth header; or
>
> 2) Use the new Apache HTTP client code.
>
> I will try and look into this on Friday (we can view this as a
> modification rather than additional features :-) ).
>
I didn't feel quite as compelled to worry about a filter on the client
side, since the client module is basically encapsulating the service API
for the calling application anyway. But it's certainly feasible.
> Paul.
Craig