[Jetty-support] Re: Jetty seems to be overriding security constraints

[Greg W. <gr...@mo...>]

Ike,

Make sure the class is only on the system classpath.  If it is
used by a Realm, then it is beyond a webapp scope.

Also, you probably want to turn on java2compliant class loading
to avoid issues like this if there are duplication.  See method on
HttpContext.

cheers




Ikonne, Ike wrote:
> Hi Greg,
> 
> That's the strange thing, I just did extended the Principal, then
> used  instanceof com.mycompany.KnownUser to enable me cast it back,
> but then, I get Class cast expection.
> 
> I am thinking though whether it has to do with the ClassLoader inside the
> servlet versus the ClassLoader that was used to create the KnownUser Object
> after authentication.
> 
> Moreover, I don't have access to the session object in the HttpRequset 
> object
> during the authentication.
> 
> Here are some tracing ...
> 
> 
> Inside HashUserRealm.authenticate
> Username: admin
> credentials: admin
> User: admin  already authenticated .....
> Using first time authenticator.authenticatd ....
> inside isUserRole
> ServletHttpContext:jSecurityCheck:
> User principal : admin
> Method : PROPFIND
> ServeResoure:PrincipalName: admin
> CeuW:MY Name is: com.sterlingcommerce.ceu.admin.KnownUser
> CEUW:Name: known_user
> CEUW:Name: org.mortbay.http.HttpListener
> ServeResoure:kuser is null:
> 
> ADMIN[0] 18:06:28,332 WARN  jetty - Exception for /ceudav/
> java.lang.ClassCastException: com.sterlingcommerce.ceu.admin.KnownUser
>         at 
> com.sterlingcommerce.ceu.admin.CeuWebdavServlet.service(CeuWebdavServlet.java:418)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>         at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
>         at 
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
>         at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:574)
>         at org.mortbay.http.HttpContext.handle(HttpContext.java:1823)
>         at 
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
>         at org.mortbay.http.HttpContext.handle(HttpContext.java:1773)
>         at org.mortbay.http.HttpServer.service(HttpServer.java:889)
>         at org.mortbay.http.HttpConnection.service(HttpConnection.java:790)
>         at 
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:961)
>         at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
>         at 
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
>         at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:300)
>         at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:511)
> 
> As you can see from the trace, the Principal identifies itself as the 
> correct
> class, but when I cast, I get a class Cast Exception.
> 
> Now this only happens when I associate this servlet with web.xml, when
> I load the servlet without any warfile/web.xml associated, every thing
> works fine.
> 
> But, I really need  the web.xml so that I may propagate configuration
> information from there.  So, what is happening?  It seems to either
> because of different class loader or something that WebApplicationContext is
> doing.
> 
> Anyone has a better suggestions?
> 
> 
> Cheers,
> 
> Ike
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Greg Wilkins [mailto:gr...@mo...]
> Sent: Thu 11/25/2004 6:53 AM
> To: Ikonne, Ike
> Cc: jet...@li...
> Subject: Re: Jetty seems to be overriding security constraints
> 
> 
> 
> Ike,
> 
> you can't really use Request attributes for this, as the same authentication
> path may not be followed for each request.
> 
> I would add the extra information to a class derived from Principal - your
> servlet could then check the type of the Principal and caste it.
> 
> Or you could just put the info in the session?
> 
> cheers
> 
> Ikonne, Ike wrote:
>  > Hi Greg,
>  >
>  > I just want to thank you and the entire group for all the pointers 
> that you
>  > have provided so far, the pathContext and servletMapping information has
>  > been
>  > exceptionally helpful.
>  >
>  > There is still a little mystery that I have not been able to resolve so
>  > far and
>  > that is:
>  >
>  > After I have authenticated my client in HashUserRealm.authenticate, I 
> would
>  > like to pass some data to my servlet.
>  >
>  > I have tried using the follwoing mechanisms, but have to been able to
>  > get it to work.
>  > Here is what I am doing inside HashUserRealm.authenticate, by the way, I
>  > extend
>  > your jetty's HashUserRealm in order to do this.
>  >
>  > request.setAttribute(attrName, attr) --- did not work, when I tried to
>  > get the
>  > attribute inside the servlet, it returns null.
>  >
>  > I have also tried to extend the the KnownUser and inside the Servlet I
>  > tried to
>  > cast the getUserPrincipal() but did not work.
>  >
>  >
>  > My question is this, how could someone pass data to the servlet from the
>  > point
>  > where user is being authenticated using jetty?
>  >
>  > Thanks,
>  >
>  > Ike
>  >
>  >
>  >
>  >
>  >
>  >
>  > -----Original Message-----
>  > From: Greg Wilkins [mailto:gr...@mo...]
>  > Sent: Sun 11/21/2004 5:32 AM
>  > To: jet...@li...
>  > Subject: Re: Jetty seems to be overriding security constraints
>  >
>  >
>  > Ike,
>  >
>  > I think your problem is that there are two related - but different
>  > mechanisms.
>  >
>  > The SecurityHandler handles security constraints when you are not using
>  > webapplications.  It is used in combination with ServletHandlers and
>  > FileHandlers.
>  >
>  > The webapplicationHandler is an extended servlet handler with security
>  > handling
>  > built in.  So you should either just use webapplications or
>  > securityhandlers, but
>  > not both.
>  >
>  > When using a webapplicationcontext, the configuration of a authenticator
>  > will be
>  > handled for you.
>  >
>  >
>  > Ikonne, Ike wrote:
>  >  > Hi all,
>  >  >
>  >  > I wil try another angle to my previous question:  It seems to me 
> that if
>  >  > I load a servlet using
>  >  >
>  >  > server.addWebapplicationContext( .......)
>  >  >
>  >  > that jetty won't let me override the security constraints using the
>  >  > established web context.  Is there any reason
>  >  > for this?
>  >  >
>  >  > What I am trying to accomplish is to have a basic web.xml associated
>  >  > with this servlet , and then
>  >  > initialize the related security constraints dynamically.  I have jetty
>  >  > embedded in my application.
>  >  >
>  >  > Any suggestions will be highly appreciated ...
>  >  >
>  >  >
>  >  > Cheers,
>  >  >
>  >  > Ike
>  >  >
>  >
>  >
> 
>