Hi Kevin,
IIRC some people are using Spring AOP. Some are using the
ComponentProvider iface to provide Java proxies.
I want to support @RolesAllowed on methods. This area will improve for
EE 6 integration. I want to avoid re-inventing a solution specific to
Jersey if we can leverage EE 6 technologies like WebBeans and EJBs.
Another solution is to demarcate your Jersey apps using Servlet and
then use a servlet filter or web-based auth support.
Paul.
On Oct 21, 2008, at 1:31 AM, Kevin Duffey wrote:
> Yes, a servlet filter could... I was thinking more along the lines
> of some sort of annotation that you can pass the Authorization
> header to and the method being invoked along with the authorization
> header could be passed in, allowing a single method to control
> whether or not the user is authorized to make a request to the
> requested method. Not sure where to draw the line tho... when does
> this start becoming annotation hell and no longer convenient.
>
>
> From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
> To: users_at_jersey.dev.java.net
> Sent: Monday, October 20, 2008 1:49:18 PM
> Subject: Re: [Jersey] Filter configuration feature
>
> Kevin Duffey wrote:
> > Hey all,
> >
> > I am curious if this discussion would include the ability to provide
> > some sort of cross-cutting "aop" like ability to check the
> > Authorization header. I haven't looked at all the latest threads,
> but
> > one issue I am trying to figure out is how to avoid doing a method
> > lookup for authorization based on the auth header, in every one of
> my
> > API methods. Maybe Jersey supports some sort of web.xml
> configuration
> > that allows me to specify a method to call with the Authorization
> > info... so that I can remove the same lookup code I have in every
> one
> > of my methods... or does this basically fit into the filter
> > configuration discussion and thus is presently not possible?
> >
> Couldn't a servlet filter do this for you, since you're using a
> servlet
> based webapp?
>
> On the other hand, I can see how abstracting authentication could be
> useful ... but an authorization check might still need a per-method
> call
> anyway so that you know what operation you're trying to authorize.
>
> Craig
>
> >
> > > Paul Sandoz wrote:
> > >>
> > >> On Oct 16, 2008, at 6:50 PM, Craig Iverson wrote:
> > >>
> > >>> First let me thank you for all the good work you guys are doing
> > >>> with jersey and jsr-311. It's been a pleasure to develop
> against.
> > >>
> > >> Thanks!
> > >>
> > >>
> > >>>
> > >>> I have a feature request that I can add to the issue tracker if
> > >>> you agree.
> > >>
> > >> Please. No need to ask permission to log issues :-)
> > >>
> > >>
> > >>> I think it would be great to be able to configure a filter per
> > >>> resource(s). In my case its even more than that, it would be
> > >>> more beneficial to also support an exclude list. I have a case
> > >>> where I only want certain filters applied to certain
> resources. I
> > >>> really want a couple of filters to always be applied except
> for on
> > >>> a couple of resources. The reason for the exclude list would
> > >>> allow other team members to add resources without worrying about
> > >>> configuring the filter for the new resource. Your thoughts?
> > >>
> > >> Currently request and response filters are called before resource
> > >> matching is performed. Having filters apply to specific root
> > >> resource classes could also make sense, but i wonder if the
> exclude
> > >> list complicates matters, especially if there is more then one
> > >> filter present in the filter chain, rather than being explicit
> and
> > >> describing the list of resources with the list of filters e.g.
> > >>
> > >> Map<List<Class<??>, List<ContainerRequestFilter>>
> > >>
> > >> I am wondering if it is appropriate to have filters associated
> with
> > >> resources and resource methods configured from the resources
> > >> themselves. How about allowing the following:
> > >>
> > >> @RequestFilters({A.class, B.class})
> > >> @Path("resource")
> > >> public class Resource {
> > >>
> > >> @RequestFilters({C.class, D.class})
> > >> @GET
> > >> public String get() { ... }
> > >>
> > >> @RequestFilters({E.class, F.class})
> > >> @Path("sub-resource")
> > >> public Object getSubResource() { ... }
> > >> }
> > >>
> > > Just as a comparison point, this is conceptually pretty similar to
> > > how you can define interceptors on EJB session beans in the bean
> > > classes themselves:
> > >
> > > @Stateless
> > > // Class level interceptors around all method calls
> > > @Interceptors({TracingInterceptor.class})
> > > public class MySessionBean {
> > >
> > > // Method level interceptors around calls to this method
> > > @Interceptors({SomeInterceptor.class,
> AnotherInterceptor.class})
> > > public String result(String arg1, String arg2) {
> > > ... business logic goes here ...
> > > }
> > >
> > > }
> > >
> > > There are also some additional ideas in EJB interceptors that
> might
> > > be worth emulating:
> > >
> > > * @ExcludeClassInterceptors and @ExcludeDefaultInterceptors
> > > to turn off normal interceptors for a particular class or method.
> > >
> > > * @AroundInvoke to let you specify the logic of a class
> interceptor
> > > inline in the same class, rather than requiring it to be separate.
> > >
> > > Of course, once you get into a world of multiple layers of
> > > interceptors, the invocation order needs to be clearly defined as
> > > well.
> > >
> > > Craig
> > >
> > >
> > >> Paul.
> > >>
> > >>>
> > >>> Craig
> > >>>
> > >>>
> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > <mailto:users-help_at_jersey.dev.java.net>
> > >>>
> > >>
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > <mailto:users-help_at_jersey.dev.java.net>
> > >>
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > <mailto:users-help_at_jersey.dev.java.net>
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > <mailto:users-help_at_jersey.dev.java.net>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com