Les,

Sorry for the late reply... I guess my thoughts on integrating with
REST were more related to dealing with and customizing error
conditions.  For instance:

@GET
@Path("process")
@RequiresPermissions("payments:process")
public Response processPayments() {
        billingService.processPendingFuturePayments();
        return Response.ok().build();
}

If a user without "payments:process" permissions hits this REST
endpoint, they will get back a 500 error with a plain text stack trace
and such. I would like to be able to respond instead with a 401 and a
JSON object that describes the error condition in a way that a client
can process it.

What I've been doing instead is moving the Shiro annotation to my
service methods instead. Then I can catch the exception inside my
jersey resource method and respond appropriately:

@GET
@Path("process")
public Response processPayments() {
        try {
                // this service method has shiro annotation
                billingService.processPendingFuturePayments();
                return Response.ok().build();
        } catch (UnauthorizedException e) {
                return Response.status(Response.Status.UNAUTHORIZED)
                        .build();
        }
}

This seems kind of messy to me. I'm sure there is a better solution,
but I haven't taken the time to find it. I thought perhaps your REST
efforts might address this, but maybe it is out of scope. There may
even be some Jersey feature I could use to solve this.

This does bring up another question -- should the REST resource or the
service method be secured with a shiro annotation? If my service
methods may be called from somewhere other than the jersey resource, I
should secure them. But what if my jersey resource does something else
(not that they do)? It seems strange to not secure it as well. But
this means that the shiro authorization code would run twice for rest
calls. Any thoughts?

Tauren


On Tue, Apr 5, 2011 at 9:34 AM, Les Hazlewood <[email protected]> wrote:
> Hi Tauren,
>
> I'm not sure Shiro would need to integrate with Jersey or other JAX-RS
> framework: they're annotation-based, so if you define Shiro
> annotations on the same methods that are JAX-RS-annotated, you'd have
> a Shiro-secured REST endpoint.  Unless I'm missing something?
>
> There is also the out-of-the-box HttpMethodPermissionFilter (aka the
> 'rest' filter) that can secure URL endpoints for REST apps even if
> you're not using a REST framework like Jersey.
>
> Is there anything else necessary?
>
> Les
>
> On Mon, Apr 4, 2011 at 9:25 PM, Tauren Mills <[email protected]> wrote:
>> Les,
>> I think it's great you are working on REST support. Is your work going to
>> integrate with REST frameworks such as Jersey?
>

Reply via email to