[Jersey] Re: looking for helping hand on securing service

From: Django <>
Date: Fri, 8 Aug 2014 06:28:27 +0200


On Friday 08 August 2014 - 00:19:57, Oleksiy Stashok wrote:
> in Grizzly there is no out-of-the-box support for digest authentication,
> but it's possible for write it using Grizzly Filters API... still I'm
> not sure how it supposed to work along with Jersey annotations (if it's
> needed).

I'm pretty new to jersey and grizzly, so I don't know, where the cut of
responsibility is.

From my little POC I would suppose, that grizzly handles all socket related
stuff, whereas jersey comes into play for request processing. But path related
filtering could be a role of both frameworks ...

As authorization requires intermediate responses/requests, responsibility is
not clear at first sight ...

> If you chose to implement this using Grizzly Filters - please let me
> know, I'll try to provide you more information.

Yes please.

Currently the resource is bound neither to jersey nor to grizzly and i like
that. The import section of the resource looks like:


So jersey is almost invisible. Pretty good :)

A ContainerRequestFilter is the right place for authorization from my point of
view, but it is not always invoked. With authorization, the import section of
ContainerRequestFilter looks like

import org.glassfish.jersey.server.ContainerRequest;
import org.glassfish.jersey.server.internal.process.MappableException;

I'm not happy about the jersey import at this level of code but I don't want
to have "internal" imports.
Currently the main-class is the only class, with a grizzly related import.
That's acceptable. If I change runtime environment, I have to replace the
main-class only.

I'd like to achieve something similar with authentication/authorization. A
Filter that works at abstraction level would be great. A Filter
with jersey dependencies I would consider acceptable, but a Filter with
grizzly dependencies is possible, but if I could avoid it, I would prefer

What I don't understand is the fact, that a ContainerRequestFilter will be
triggered for non protected paths but not for protected paths. From my point
of view, it should be triggered before resource filtering.

I would appreciate it a lot, if someone could shine me a light on workflow
conception and cut of responsibility between grizzly and jersey.

br Django