On Dec 2, 2008, at 3:58 PM, Rod Fitzsimmons Frey wrote:
> Thanks, Paul. I really need a custom realm, though, since I’m using
> salted hashed passwords in a mySql database, which the JDBCRealm
> doesn’t seem to support.
>
OK. I suggest you send an email to users_at_glassfish.dev.java.net
> In any event, a servlet authentication filter would be fine if I
> could understand the relationship between the web container and
> Jersey.
If you are using app/web server authentication then you can inject:
@Context SecurtyContext sc;
which is similar to methods exposed on HttpServletRequest to get
access to the principle.
If you are rolling your own auth i recommended creating your own
injectable provider with your own type encapsulating the principle.
> It seems to have something to do with the @Context annotation,
> but I can’t find any documentation on that or examples, only
> references to how you can use it to obtain container resources.
If you want to get access to the HttpServletRequest do:
@Context HttpServletRequest hsr
as a field, constructor parameter, or method parameter. ServletContext/
ServletContext/HttpServletResponse are also supported.
> I found something (might have been from you!) showing how to get a
> ResourceContext object… but I don’t know what to do with that once I
> get it.
That is something different, that gets you instances of other resource
classes that are deployed.
> My google-fu is failing me completely.
Have you read the following:
http://wikis.sun.com/display/Jersey/Overview+of+JAX-RS+1.0+Features
?
Paul.
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Tuesday, December 02, 2008 7:48 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] Communicating with Jersey from servlet filter
>
> Hi Rod,
>
> On Dec 2, 2008, at 3:33 PM, Rod Fitzsimmons Frey wrote:
>
>
> I’m having a lot of trouble creating a custom realm in Glassfish,
> which I’m trying to work through on the Glassfish list.
>
>
> The following may help you:
>
> http://markmail.org/message/oz3gukd2cnhsces6?q=list:net.java.dev.jersey.users+realm
> http://markmail.org/message/gplle5rtvapfyeog?q=list:net.java.dev.jersey.users+realm
>
> But i agree this could be made a lot easier.
>
>
>
> To keep moving forward, I’ve implemented a servlet filter to do
> authentication.
>
> However, I’m unclear on the best way to communicate with my Resource
> classes from the servlet container. Back in the day, I’d stuff an
> object (in this case the authenticated user) into the
> HttpServletRequest using setAttribute, or if it was long lived into
> the session. Obviously restful objects don’t have a session concept
> since they’re stateless, but I’d still like to communicate with the
> resources from the filter.
>
> Am I misunderstanding a basic architectural aspect of jersey?
>
>
> No. You can still use attributes on the HttpServletRequest if you
> wish as this can be injected into resource classes with @Context.
>
> A pattern that is useful is to create your own injectable object
> that wraps around the properties set on HttpServletRequest. For
> example you could do:
>
> @Provider
> public MyXYZProvider extends
> PerRequestTypeInjectableProvider<Context, XYZ> {
> @Context HttpServletRequest hsr
>
> public abstract Injectable<T> getInjectable(ComponentContext ic,
> Context a) {
> return new Injectable<XYZ>() {
> public XYZ getValue() {
> // get attributes from hsr
> return new XYZ(...);
> }
> };
> }
> }
>
> And in your resource class:
>
> @Context XYZ xyz;
>
> Note that if you don't want to bind to servlet you could use a
> Jersey filter and set properties on @HttpContext. The nice thing
> about using an injectable provider is that such details are hidden
> from the resource classes.
>
> Paul.