On Feb 4, 2009, at 7:43 PM, Craig McClanahan wrote:
> 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).
I just realized that the way things are currently supported you will
need supply two injectable provider implements for the per request and
singleton scope (where the latter injects a proxy) and there are
currently some ordering issues in that the latter cannot currently be
overridden by the user.
Since this is something that seems highly desirable i am going to
tweak the ContainerRequest so that a SecurityContext implementation
can be set. That way the filter can do:
request.setSecurityContext(...)
Paul.
>
>>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>