Hi Libor,
thank you for your attention.
On Thursday 07 August 2014 - 14:23:29, Libor Kramolis wrote:
> The functionality depends on container. Jersey servlet/application must be
> secured by container, e.g. security-constraint and login-config web.xml
well, I don't want to do configuration by xml-coding
> ... Jersey then delegates security checks to appropriate container. Try to
> find out how to secure grizzly server similar way as servlet.
Referring to the jersey sample "https-clientserver-grizzly" - that's the way,
I'd like to setup my service.
I did not find a working sample using digest authentication. May be I got
things wrong. Jersey userguide states (5.9.1): Jersey supports Basic and
Digest Http authentication.
I wonder, how that support looks like?
When I look at AuthenticationExceptionMapper it looks like I have to code the
Authentication header myself. That's no problem, but if there's any support
for authentication in jersey, I would like to use it.
The @RolesAllowed annotation looks like resource filtering to me, but not as
authorization support. So what's the right way to get into play when such a
resource will be requested without authentication header?
Is it possible to mix @RolesAllowed with ContainerRequestFilter?
The other way would be, extend each resource method with @Context HttpHeaders
and do all restrictions myself? Does it mean, I may not use @RolesAllowed
annotations?
br Django