23 messages in net.java.dev.jersey.usersRe: [Jersey] Getting ready for 1.0.2 ...| From | Sent On | Attachments |
|---|---|---|
| Paul Sandoz | Feb 2, 2009 1:45 am | |
| Craig McClanahan | Feb 2, 2009 11:44 am | |
| Martin Grotzke | Feb 2, 2009 6:02 pm | |
| Paul Sandoz | Feb 3, 2009 1:24 am | |
| Paul Sandoz | Feb 3, 2009 1:33 am | |
| Martin Grotzke | Feb 3, 2009 6:59 pm | |
| Paul Sandoz | Feb 4, 2009 2:33 am | |
| Paul Sandoz | Feb 4, 2009 3:10 am | |
| Martin Grotzke | Feb 4, 2009 4:17 am | |
| Paul Sandoz | Feb 4, 2009 4:56 am | |
| Paul Sandoz | Feb 4, 2009 9:16 am | |
| Craig McClanahan | Feb 4, 2009 10:35 am | |
| Craig McClanahan | Feb 4, 2009 10:43 am | |
| tarjei | Feb 5, 2009 1:09 am | |
| Paul Sandoz | Feb 5, 2009 2:12 am | |
| Paul Sandoz | Feb 5, 2009 2:20 am | |
| tarjei | Feb 5, 2009 2:43 am | |
| Paul Sandoz | Feb 5, 2009 4:24 am | |
| Craig McClanahan | Feb 5, 2009 9:10 am | |
| Craig McClanahan | Feb 5, 2009 1:27 pm | |
| Paul Sandoz | Feb 6, 2009 1:50 am | |
| Craig McClanahan | Feb 6, 2009 11:53 am | |
| Paul Sandoz | Feb 10, 2009 1:41 am |
| Subject: | Re: [Jersey] Getting ready for 1.0.2 (WAS: Re: [Jersey] Extract ResourceDoclet from maven-wadl-plugin as new artifact) | |
|---|---|---|
| From: | Paul Sandoz (Paul...@Sun.COM) | |
| Date: | Feb 5, 2009 2:20:43 am | |
| List: | net.java.dev.jersey.users | |
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.