Hello,
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:
import javax.annotation.security.PermitAll;
import javax.annotation.security.RolesAllowed;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
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 java.io.IOException;
import java.security.Principal;
import javax.ws.rs.NotAuthorizedException;
import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerRequestFilter;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.SecurityContext;
import javax.ws.rs.core.UriInfo;
import javax.ws.rs.ext.Provider;
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 javax.ws.rs 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
others.
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