Custom HTTP status response with JAX-RS (Jersey) and @RolesAllowed

Question

With my very simple JAX-RS service I'm using Tomcat with JDBC realm for authentication, therefore I'm working the the JSR 250 annotations.

The thing is that I want to return a custom message body in the HTTP status response. The status code (403) should stay the same. For example, my service looks like the following:

@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 ...;
    }
}

If a user with a different role than "ADMIN" access the service, I want to change the response message to something like that (depending on the media type [xml/json]):

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

At the moment Jersey returns the following body:

HTTP Status 403 - Forbidden

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

How can I change the default message body? Is there a way to handle the (maybe thrown) exception to build my own HTTP status response?

Onomasiology

A complete example: bhaveshthaker.com/25/… – Tocci

Answer 1

The easiest way to handle this sort of thing is to throw an exception and to register an exception mapper to convert into the kind of message you want to send in that case. So, suppose you throw an AccessDeniedException, you would then have a handler like this (with full class names in places for clarity):

@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();
    }
}

The way in which you register the exception mapper varies according to the framework you're using, but for Jersey you should be fine with just using @Provider. I'll let you figure out for yourself how you want to generate the kind of error documents that you want, but I do recommend handling failures as HTTP error codes of some kind (that's more RESTful...)

Bartizan

The thing is that Jersey returns it's custom 403 response. I'm not able the throw the AccessDeniedException for authorization since the @RolesAllowed stuff handles this. The HTTP error code should be the some I just want to change the body message. – Onomasiology

I thought you could do that in Jersey with an ExceptionMapper; I know you can with Apache CXF (though that's configured differently for reasons I've come to appreciate) so I believed it reasonable to at least try given that they're both JAX-RS engines and this is just using the JAX-RS API, but I've no direct experience with Jersey so maybe there's something unexpected in the way. – Bartizan

Answer 2

With creating an ExceptionMapper (mapping exceptions of WebApplicationException) it is possible to "catch" certain exceptions thrown by the application:

@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();
    }
}

You also need to add the package to your application web.xml for registering the provider:

<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>

Onomasiology

I was facing the same problem and in my case that was the perfect answer. Thanks Stefan! – Darbies

Answer 3

REST is build upon HTTP so you don't have to change the default behavior of an authentication failure. Having a 403 error when accessing a resource is enough for the client to clearly understand what appends.

The more your resources are HTTP compliant, the more others can understand it.

Uncle

the problem is there can be various situations a single http error occours. One can be a session time out (results in 403) managed by the AS. Another can be an unauthorized attemp to a rest resource (403). If you have to programmatically react in different ways on those errors its a good way to customize thems. – Darbies

@Darbies I think you could use a custom http code 4## in this case. The first number decides the category. 4 means "the request contains bad syntax or cannot be fulfilled" – Belkisbelknap