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?
Paul.
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>