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

From: Django <>
Date: Sat, 9 Aug 2014 07:36:47 +0200

On Saturday 09 August 2014 - 04:30:20, Tom Samplonius wrote:
> > On Aug 8, 2014, at 8:40 AM, Django wrote:
> >> On Friday 08 August 2014 - 07:58:51, Libor Kramolis wrote:
> >>
> >> Why do you use Grizzly container? And why you don’t use Servlet
> >> container?
> >
> > I want a small footprint service. My first thought was about
> > HttpComponents, but then I read about jersey ...
> Have you thought about Dropwizard? It uses Maven too, but Dropwizard is
> much more minimal. You can even build single JAR deployables.

Huh - I didn't know Dropwizard. Sounds very promising. Thanks a lot for the
hint! I'd love to go for it after resolving my jersey issues.

Some more words about not using servlet containers:
First thought was of cause the size of those containers, the installation
impact ...

... but on a closer look:
rest services will quite common have restricted and unrestricted calls using
the same resource. So if I use a servlet container to secure a call, servlet
containes have to evaluate request path.
But request path evaluation is the biggest goal of jersey.
I don't like having the same processing twice in a workflow.
So for me, its not the question servlet container and jersey but servlet
container or jersey.
I like the jersey way, so I lend servlet containers to others ;)

> The typical reason why Maven downloads so many things, is because there are
> so many dependencies. That's not Maven's fault.

That may be true. But maven forces each installation target have internet
access at rollout time - that's not true for most of my installations.
Any way - Dropwizard looks like being able to convert me into a maven user :O

... but back to topic:
Dropwizard does not change anything related to current issue.

... but reading the chapter "Jersey filters" from Core User Manual pushed me to
try something similar ...
... especially in conjunction with the comment from line 113 of
RolesAllowedDynamicFeature source.

... with the result, that Dropwizard refers to an outdated jersey version and
that multiple filter support seems to be dropped in current jersey release.

The comment from line 113 suggests, that a ContainerRequestFilter with higher
priority could come into play earlier ...

So I build a ContainerRequestFilter annotated with

... but it did not change anything.

So I suspect, that jersey does not support any ContainerRequestFilter coming
into play before the internal one. What about a wrapping
ContainerRequestFilter like this:

private static class CheckAuthHeader implements ContainerRequestFilter {
    CheckAuthHeader() {
        rolesFilter = new RolesAllowedRequestFilter();

    CheckAuthHeader(String[] rolesAllowed) {
        rolesFilter = new RolesAllowedRequestFilter(rolesAllowed);

    public void filter(ContainerRequestContext ctx) throws IOException {
        AnnotatedMethod am = new AnnotatedMethod(??? convert2Method(
extendedUriInfo.getMatchedResourceMethod() ));
        String authHeader = ctx.getHeaderString(HttpHeaders.AUTHORIZATION);
        RolesAllowed ra = am.getAnnotation(RolesAllowed.class);

        if (ra != null && authHeader == null)
            throw new NotAuthorizedException("Auth Header was not specified",

    ExtendedUriInfo extendedUriInfo;
    private RolesAllowedRequestFilter rolesFilter;

lines 87, 94 and 109 should then changed to create a CheckAuthHeader instance
instead of a RolesAllowedRequestFilter instance.

I don't want the RolesAllowedDynamicFeature to enforce to build a HttpResponse
(as the constructor of NotAuthorizedException implies). That should be the job
of ExceptionMappers ...

could this suggestion be a way to enable authentication at jersey level?

br Django