4

I'm using ReastEasy in a JBoss-7 environment and currently implementing security features. I'm using HTTP Basic with an SSL connection. Adding and evaluating the header parameter is easy (Thanks to Passing parameters in the message header with a REST API):

@Provider @ServerInterceptor
public class RestSecurityInterceptor implements PreProcessInterceptor
{
  @EJB MyBean fUser;
  private MyUser user;  

  @Override
  public ServerResponse preProcess(HttpRequest request, ResourceMethod method)
                                                     throws UnauthorizedException
  {
     // do some some stuff. If the request is authenticated I get a MyUser      
    user = ...
  }

  @Named @Produces @SessionScoped
  public MyUser getCurrentUser() {return user;}
}

This works fine, also the @Produces and @Inject in my REST service work like a charm.

@Path("/rest")
public class MyService extends Application
{
  @Inject private MyUser currentUser;

  @GET @Path("/test")
  public String test()
  {
    return "Hello "+currentUser.getName();
  }
}

Now my question: Is it safe to implement the security for REST this way (I don't want a discussion about HTTP Basic pro/cons, let's focus on CDI)? Especially I'm wondering if I can use CDI like described and if I have chosen the right scope with @SessionScoped?

Community
  • 1
  • 1
Thor
  • 6,607
  • 13
  • 62
  • 96

1 Answers1

0

Session scope won't work. There have already been a few questions about REST and the session scope. The session scope is not active for JAX-RS nor JAX-WS calls.

LightGuard
  • 5,298
  • 19
  • 19
  • In my application, I inject an `@SessionScoped` POJO `A` into a REST endpoint which has default scope. After the first call to this endpoint, all subsequent calls of the same client get the instance of `A` that is bound to its session. My interpretation of this situation is that session scope works for JAX-RS and is active; or did I misunderstood something? – kraftan May 06 '12 at 08:49
  • Interesting, it shouldn't be active, because there's nothing by default to tie requests to a particular session. Section 6.7.2 of the CDI spec doesn't mention it being active for web services. – LightGuard May 08 '12 at 23:36