java - chrome - resteasy example

¿Cuál es el reemplazo adecuado del InterprocessInterceptor Resteasy 3.X?

Question

Estoy creando el servicio de descanso utilizando un mecanismo de autenticación / autorización como se describe en este tutorial: http://howtodoinjava.com/2013/06/26/jax-rs-resteasy-basic-authentication-and-authorization-tutorial/

Básicamente, utiliza la interfaz PreProcessInterceptor para escanear el método de destino en busca de anotaciones (del paquete javax.annotation.security ) que describen los roles necesarios para acceder a ese método. Como el autenticador aquí es un interceptor, puede cancelar la invocación del método de destino, devolviendo un 401 (no autorizado) si es necesario.

El problema aquí es que la interfaz org.jboss.resteasy.spi.interception.PreProcessInterceptor está obsoleta en la versión actual de RestEasy (3.0.1), y tengo problemas al intentar implementar el mismo comportamiento con las interfaces estándar JAX-RS .

Estoy usando la interfaz javax.ws.rs.ext.ReaderInterceptor para interceptar la llamada. Pero de alguna manera el servidor nunca lo llama: el interceptor simplemente es ignorado.

Estoy registrando los interceptores / recursos de la misma manera que lo hice con el PreProcessInterceptor anterior, y uso las mismas anotaciones @Provider y @ServerInterceptor:

ServerApplication:

public class ServerApplication extends javax.ws.rs.core.Application {

     private final HashSet<Object> singletons = new LinkedHashSet<Object>();

     public ServerApplication() {
         singletons.add(new SecurityInterceptor());
         singletons.add( ... ); //add each of my rest resources
     }

    @Override
    public Set<Class<?>> getClasses() {
        HashSet<Class<?>> set = new HashSet<Class<?>>();
        return set;
    }

    @Override
    public Set<Object> getSingletons() {
        return singletons;
    }
}

Interceptor de seguridad:

@Provider
@ServerInterceptor
public class SecurityInterceptor implements javax.ws.rs.ext.ReaderInterceptor {
     @Override
     public Object aroundReadFrom(ReaderInterceptorContext context){
            //code that is never called... so lonely here...
     }
}

¿Alguna idea sobre cómo puedo resolver este problema?

Gracias.

Answer 1

RESTEasy 3.xx cumple con la especificación JAX-RS 2.0.

Lo que está tratando de hacer podría lograrse (quizás mejor) con:

@Provider
public class SecurityInterceptor 
      implements javax.ws.rs.container.ContainerRequestFilter {
     @Override
     public void filter(ContainerRequestContext requestContext){
       if (not_authenticated){ requestContext.abortWith(response)};
     }
}

ya que ReaderInterceptor se invoca solo si el ReaderInterceptor JAX-RS estándar invoca el MessageBodyReader.readFrom subyacente, no desde el código de la aplicación.

Sin embargo, la razón por la que no se llama a su interceptor podría ser la anotación @ServerInterceptor , que es una extensión RESTEasy.

La especificación indica en §6.5.2 que un interceptor está registrado globalmente, a menos que @Provider esté anotado con una anotación @NameBinding , pero no sé si RESTEasy puede manejar un @ServerInterceptor si no está registrado explícitamente como se muestra en RestEASY Interceptor No ser llamado

Answer 2

Si necesita obtener acceso al java.lang.reflect.Method subyacente (como solía poder obtener implementando AcceptedByMethod ), puede hacer lo siguiente:

ResourceMethodInvoker methodInvoker = (ResourceMethodInvoker) 
            requestContext.getProperty("org.jboss.resteasy.core.ResourceMethodInvoker");
Method method = methodInvoker.getMethod();

Answer 3

También quería obtener acceso al java.lang.reflect.Method subyacente y probé la respuesta de mtpettyp con Resteasy 3.0.8, pero eso estaba volviendo nulo en la llamada a getProperty. También estoy usando Spring y resteasy-spring aunque no creo que eso deba impactar en absoluto.

Si se encuentra en mi situación y está implementando un Poster MatchingRequestFilter (de alguna manera tiene que hacerlo si de todos modos esperaba obtener el método de recursos coincidentes), entonces puede lanzar ContainerRequestContext a la implementación que Resteasy tiene para el escenario Post Match. El PostMatchContainerRequestContext tiene una referencia al ResourceMethodInvoker.

public void filter(ContainerRequestContext context) throws IOException {
    PostMatchContainerRequestContext pmContext = (PostMatchContainerRequestContext) context;

    Method method = pmContext.getResourceMethod().getMethod();

    /* rest of code here */
}