On Tue, 2008-05-06 at 10:17 -0700, Andrew Cole wrote:
> Thanks for that info, Martin. Unfortunately, I am not using Spring,
> but EJBs on JBoss with Jersey and JAXB. Any other ideas?
Then you might implement your own ComponentProvider that creates your
resource classes, so that you can apply AOP-stuff by yourself.
Some information regarding a custom ComponentProvider you find at [1],
also useful is a new feature (which was introduced together with the
spring-integration) that allows you to retrieve subresources from the
ResourceContext in a resource class [2].
Cheers,
Martin
[1]
http://blogs.sun.com/sandoz/entry/integrating_jersey_and_spring_take
[2]
http://www.javakaffee.de/blog/2008/04/21/jersey-spring-integration-mostly-complete/
>
> Also, I mentioned that in the mean-time I have been using code like:
> public String verifyLogin(@QueryParam("auth") SessionToken token) {
> // do something with token...
> }
> and raising a WebApplicationException in my SessionToken constructor
> if the token is invalid, etc.. When I do this, I always get a 400 BAD
> REQUEST error even when I specify a different status code in my
> WebApplicationException. This makes sense, since Jersey must catch
> Exceptions thrown while trying to marshall objects and return the 400
> itself, but I would like to override this behavior if we don't come up
> with another way for me to achieve my desired functionality.
>
> Andrew
>
> On Mon, May 5, 2008 at 11:56 PM, Martin Grotzke
> <martin.grotzke_at_freiheit.com> wrote:
> > Hi Andrew,
> >
> > are you using an IoC-container that provides AOP-features, like e.g.
> > spring? In this case you might use AOP functionality of spring an define
> > your pointcuts and advices accordingly. Your resource classes then must
> > be managed by the IoC-container, that AOP stuff is applied.
> >
> > For spring (2.5) the introduction to their AOP integration is here [1].
> >
> > Cheers,
> > Martin
> >
> >
> > [1] http://static.springframework.org/spring/docs/2.5.x/reference/aop.html
> >
> >
> >
> >
> > On Mon, 2008-05-05 at 15:37 -0700, Andrew Cole wrote:
> > > Hi all.
> > >
> > > Just joined the list and I've read through some of the archives and
> > > didn't find quite what I was looking for. Nearest thing seems to be
> > > the Security Interceptors thread from late March.
> > >
> > > In my app I have an authentication token coming in as a query param
> > > for methods that need authentication. I can decode the authentication
> > > token and create an object with information about the user. I would
> > > like to be able to easily specify which methods need authentication,
> > > and then have the token information made available to those methods.
> > > I'm thinking that ideally I could have an annotation that works like:
> > >
> > > @GET
> > > @Path("verifyLogin")
> > > @ProduceMime("text/plain")
> > > @MyAuthAnnotation // indicates this method requires a valid session token
> > > public String verifyLogin(@MyAuthQueryParam SessionToken token) { //
> > > session token initialized from the value of the query param passed in
> > > as argument
> > > return token.getUsername() + " is logged in and has account ID: " +
> > > token.getAccountId();
> > > }
> > >
> > > The important thing is to make it as simple as possible to require
> > > authentication for a method, since this code will be used over and
> > > over for many methods.
> > >
> > > I have tried using the regular QueryParam syntax and making my
> > > SessionToken constructor accept a String argument. In the constructor
> > > I can verify that the token is valid and decode the user information.
> > > This works well except when someone calls the method without including
> > > the query parameter in the request at all. In this case, the
> > > QueryParam-annotated argument to my method is null (and I don't want
> > > to have to check for nulls in every method that requires
> > > authentication).
> > >
> > > Any ideas on how I can go about this?
> > >
> > > Thanks,
> > > Andrew
> > >
> > > ---------------------------------------------------------------------
> > > 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