You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Fernando Padilla <fe...@interdimensions.com> on 2001/03/01 22:55:11 UTC

Realm classes and ClassLoaders

I have a MyRealm class to lock down my webapp.

That works fine.  I have the jar file with the classes in
$TOMCAT_HOME/server  and within $WEB_APP/WEB_INF/lib.

The Web App needs to gain access to the username/password given to the
Realm ( right now I store it in the MyPrincipal class ), to be able to
login into a backend tier.

I try to cast the Principal ( from getUserPrincipal ), to MyPrincipal, but
it there is a ClassCastException ( though it is indeed the right class,
it's from a different class loader.. etc )....


Again, I'm trying to bridge the gap between the classloader used by the
server and the classloader used by the web app.  So that I can cast/use an
object from one classloader from the other classloader....


Ideas?? Help?? Clue?? Rants?? Raves??

just toss 'em out

fern



Re: Realm classes and ClassLoaders

Posted by Fernando Padilla <fe...@interdimensions.com>.
I'm confused. I have Realm authentication set-up.  I haven't heard about
the Authenticator API?  Is that configurable from the server.xml as well??

fern


> You would need to sublcass whichever authenticator class you are using
> (such as
> org.apache.catalina.authenticator.FormAuthenticator) and override the
> authenticate()
> method, something like this:
>
>     public boolean authenticate(HttpRequest request,
>         HttpResponse response, LoginConfig config) {
>
>         if (!super.authenticate(request, response, config))
>             return (false);
>         MyPrincipal principal =
>           (MyPrincipal) request.getUserPrincipal();
>         if (principal == null) {
>             // We are asking for the form login page
>             return (true);
>         } else {
>             // Copy the stuff we need into the session
>             HttpSession session =
>               ((HttpServletRequest) request.getRequest).getSession();
>             session.setAttribute("userStatus", principal.getStatus());
>             ...
>             return (true);
>         }
>
>     }
>
> Note that the attributes you save need to be JDK classes like String,
> because the
> user classes you store in the server directory are not visible to web
> apps.
>
> >
> > thank you :):):)
> >
> > fern
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-user-help@jakarta.apache.org
>


Re: Realm classes and ClassLoaders

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Fernando Padilla wrote:

> On Fri, 2 Mar 2001, Craig R. McClanahan wrote:
>
> > Fernando Padilla wrote:
> > >
> > > Again, I'm trying to bridge the gap between the classloader used by the
> > > server and the classloader used by the web app.  So that I can cast/use an
> > > object from one classloader from the other classloader....
> > >
> > > Ideas?? Help?? Clue?? Rants?? Raves??
> > >
> >
> > In that case, you're not going to be able to do this cast.  The classes placed
> > in $TOMCAT_HOME/server are loaded by a class loader that is not visible to web
> > applications (i.e. it is not a parent class loader to the one used for your
> > web app).
> >
> > If you have additional information from the MyUserPrincipal class that your
> > application needs to see, I suggest that you store them as request attributes
> > or session attributes inside the authenticator.  This will work for anything
> > that is a String or a Java primitive type (wrapped in the corresponding
> > wrapper class such as java.lang.Integer for an "int").
> >
>
> 1) i hear people say, to add jar file to $TOMCAT_HOME/lib, I tried that
> and that did not work, so i added them to $TOMCAT_HOME/server and that did
> work.
>

Yes, that will make your classes available to Catalina's internal class
loader.

>
> 2) request or session attributes inside the authenticator??
>    I'm using MyRealm, the interface to that is just
>    authenticate( String user, String pass ), how can I access the request
>    or session that is being authenticated??
>

You would need to sublcass whichever authenticator class you are using
(such as
org.apache.catalina.authenticator.FormAuthenticator) and override the
authenticate()
method, something like this:

    public boolean authenticate(HttpRequest request,
        HttpResponse response, LoginConfig config) {

        if (!super.authenticate(request, response, config))
            return (false);
        MyPrincipal principal =
          (MyPrincipal) request.getUserPrincipal();
        if (principal == null) {
            // We are asking for the form login page
            return (true);
        } else {
            // Copy the stuff we need into the session
            HttpSession session =
              ((HttpServletRequest) request.getRequest).getSession();
            session.setAttribute("userStatus", principal.getStatus());
            ...
            return (true);
        }

    }

Note that the attributes you save need to be JDK classes like String,
because the
user classes you store in the server directory are not visible to web
apps.

>
> thank you :):):)
>
> fern
>

Craig McClanahan

Re: Realm classes and ClassLoaders

Posted by Fernando Padilla <fe...@interdimensions.com>.
On Fri, 2 Mar 2001, Craig R. McClanahan wrote:

> Fernando Padilla wrote:
> >
> > Again, I'm trying to bridge the gap between the classloader used by the
> > server and the classloader used by the web app.  So that I can cast/use an
> > object from one classloader from the other classloader....
> >
> > Ideas?? Help?? Clue?? Rants?? Raves??
> >
> 
> In that case, you're not going to be able to do this cast.  The classes placed
> in $TOMCAT_HOME/server are loaded by a class loader that is not visible to web
> applications (i.e. it is not a parent class loader to the one used for your
> web app).
> 
> If you have additional information from the MyUserPrincipal class that your
> application needs to see, I suggest that you store them as request attributes
> or session attributes inside the authenticator.  This will work for anything
> that is a String or a Java primitive type (wrapped in the corresponding
> wrapper class such as java.lang.Integer for an "int").
> 


1) i hear people say, to add jar file to $TOMCAT_HOME/lib, I tried that
and that did not work, so i added them to $TOMCAT_HOME/server and that did
work.

2) request or session attributes inside the authenticator??
   I'm using MyRealm, the interface to that is just
   authenticate( String user, String pass ), how can I access the request
   or session that is being authenticated??


thank you :):):)

fern



Re: Realm classes and ClassLoaders

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Fernando Padilla wrote:

> I have a MyRealm class to lock down my webapp.
>
> That works fine.  I have the jar file with the classes in
> $TOMCAT_HOME/server  and within $WEB_APP/WEB_INF/lib.
>
> The Web App needs to gain access to the username/password given to the
> Realm ( right now I store it in the MyPrincipal class ), to be able to
> login into a backend tier.
>
> I try to cast the Principal ( from getUserPrincipal ), to MyPrincipal, but
> it there is a ClassCastException ( though it is indeed the right class,
> it's from a different class loader.. etc )....
>

Different class loader would not matter if it's a parent of the webapp class
loader, but (as we will see) that is not the case.

>
> Again, I'm trying to bridge the gap between the classloader used by the
> server and the classloader used by the web app.  So that I can cast/use an
> object from one classloader from the other classloader....
>
> Ideas?? Help?? Clue?? Rants?? Raves??
>

In that case, you're not going to be able to do this cast.  The classes placed
in $TOMCAT_HOME/server are loaded by a class loader that is not visible to web
applications (i.e. it is not a parent class loader to the one used for your
web app).

If you have additional information from the MyUserPrincipal class that your
application needs to see, I suggest that you store them as request attributes
or session attributes inside the authenticator.  This will work for anything
that is a String or a Java primitive type (wrapped in the corresponding
wrapper class such as java.lang.Integer for an "int").

>
> just toss 'em out
>
> fern
>

Craig McClanahan