Paul Sandoz wrote:
>
> On Feb 4, 2009, at 12:11 PM, 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!
>>
>> 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 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.
>>
>> 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.
>>
>> 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 :-) ).
>>
>
> A tip and memo to self. One can create a SecurityContext injector like
> this:
>
> @Provider
> public class SCInject implements InjectableProvider<Context, Type> {
>
> public ComponentScope getScope() {
> return ComponentScope.PerRequest;
> }
>
> public Injectable<SecurityContext> getInjectable(ComponentContext
> ic, Context a, Type c) {
> if (c != SecurityContext.class)
> return null;
>
> return new Injectable<SecurityContext>() {
> public SecurityContext getValue() {
> // return thread local instance created by container request
> filter.
> }
> };
> }
> }
>
> We could define two roles, admin and user. For the user role, the
> isUserInRole is connected to the SecurityContext could look up the
> "username" path parameter. Then we can reuse the @RolesAllowed
> annotating the resource classes.
>
> Craig, what do you think?
That sounds really good ... I'll take it on (along with using resource
specific filters).
>
> Paul.
Craig
>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>