Respuesta de estado HTTP personalizada con JAX-RS (Jersey) y @RolesAllowed

Question

Con mi servicio JAX-RS muy simple, estoy usando Tomcat con el dominio JDBC para la autenticación, por lo tanto, estoy trabajando con las anotaciones JSR 250.

Lo que pasa es que quiero devolver un cuerpo de mensaje personalizado en la respuesta de estado HTTP. El código de estado (403) debe permanecer igual. Por ejemplo, mi servicio tiene el siguiente aspecto:

@RolesAllowed({ "ADMIN" }) 
@Path("/users") 
public class UsersService { 

    @GET 
    @Produces(MediaType.TEXT_PLAIN) 
    @Consumes({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) 
    public String getUsers() { 
     // get users ... 
     return ...; 
    } 
} 

Si un usuario con una función diferente de "admin" acceder al servicio, quiero cambiar el mensaje de respuesta a algo así (dependiendo del tipo de medio [ XML/JSON]):

<error id="100"> 
    <message>Not allowed.</message> 
</error> 

Por el momento Jersey devuelve el siguiente cuerpo:

HTTP Status 403 - Forbidden 

type Status report 
message Forbidden 
description Access to the specified resource (Forbidden) has been forbidden. 
Apache Tomcat/7.0.12 

¿Cómo puedo cambiar el cuerpo del mensaje por defecto? ¿Hay alguna forma de manejar la excepción (tal vez lanzada) para construir mi propia respuesta de estado HTTP?

Answer 1

La manera más fácil de manejar este tipo de cosas es lanzar una excepción y registrar un asignador de excepciones para convertirlo en el tipo de mensaje que desea enviar en ese caso. Así, supongamos que usted lanza una AccessDeniedException, entonces tendría un controlador como este (con nombres de clase completos en lugares para mayor claridad):

@javax.ws.rs.ext.Provider 
public class AccessDeniedHandler 
     implements javax.ws.rs.ext.ExceptionMapper<AccessDeniedException> { 
    public javax.ws.rs.core.Response toResponse(AccessDeniedException exn) { 
     // Construct+return the response here... 
     return Response.status(403).type("text/plain") 
       .entity("get lost, loser!").build(); 
    } 
} 

La forma en que se registra el asignador excepción varía de acuerdo con el marco que' reutilizando, pero para Jersey deberías estar bien con solo usar @Provider. Dejaré que descubras por ti mismo cómo quieres generar el tipo de documentos de error que deseas, pero recomiendo manejar fallas como códigos de error HTTP de algún tipo (eso es más RESTful ...)

Answer 2

Con la creación un ExceptionMapper (excepciones mapeo de WebApplicationException) es posible "atrapar" ciertas excepciones producidas por la aplicación:

@Provider 
public class MyExceptionMapper implements ExceptionMapper<WebApplicationException> { 

    @Override 
    public Response toResponse(WebApplicationException weException) { 

     // get initial response 
     Response response = weException.getResponse(); 

     // create custom error 
     MyError error = ...; 

     // return the custom error 
     return Response.status(response.getStatus()).entity(error).build(); 
    } 
} 

también es necesario añadir el paquete a su web.xml solicitud de registro del proveedor:

<init-param> 
    <param-name>com.sun.jersey.config.property.packages</param-name> 
    <param-value> 
     com.myapp.userservice; // semi-colon seperated 
     com.myapp.mappedexception 
    </param-value> 
</init-param> 

Answer 3

REST se basa en HTTP, por lo que no tiene que cambiar el comportamiento predeterminado de un error de autenticación. Tener un error 403 al acceder a un recurso es suficiente para que el cliente entienda claramente lo que se agrega.

Cuantos más recursos cumplan con HTTP, más podrán entenderlo otros.