Koji,
(1) Make sure you understand the implications of directly using any of Tomcat's internal classes (such as o.a.coyote.tomcat5.CoyoteRequest) -- especially to circumvent intended security. It is rarely advisable.
If you still want to use it, move the class and/or jar into the $TOMCAT_HOME/common/classes or $TOMCAT_HOME/common/lib directory. It will be accessible to both Tomcat and your webapps in this case.
Repeat (1).
justin
At 08:15 PM 5/27/2004, you wrote:
Hi again,
I found org.apache.coyote.tomcat5.CoyoteRequest class has a method setUserPrincipal which seems to be used to memorize authenticated user's principal into session. So I think I can call this method to authenticate users as soon as they register. But at runtime, when a user register himself and a regiter program (struts action) trys to call the method, the following exception occured:
java.lang.NoClassDefFoundError: org/apache/coyote/tomcat5/CoyoteRequest sample.action.SubscribeAction.execute(SubscribeAction.java:34)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces sor.java:484)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
This is because of Tomcat class loader problem. The Tomcat document says,
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html "Catalina - This class loader is initialized to include all classes and resources required to implement Tomcat 5 itself. These classes and resources are TOTALLY invisible to web applications."
So, I think I cannot call CoyoteRequest.setUserPrincipal(). Any idears?
regards,
Koji
> -----Original Message-----
> From: Koji Sekiguchi [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 26, 2004 11:58 AM
> To: Tomcat Users List
> Subject: RE: API for authenticating user
>
>
> Redirecting to j_security_check is a nice idea.
> Yes, I know Servlet specification doesn't have such API.
> But Tomcat must implement a mechanism that associates
> user principal with http session so that servlets can get
> user principal by calling HttpServletRequest.getUserPrincipal().
> So I'll check Tomcat implementation of the API (getUserPrincipal())
> to see how Tomcat memorizes user principal.
>
> Koji
>
> > -----Original Message-----
> > From: Matt Raible [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 26, 2004 11:26 AM
> > To: Tomcat Users List
> > Subject: Re: API for authenticating user
> >
> >
> > Unfortunately, there is not an API for this in J2EE or
> > container-managed authentication. I accomplish this in an example app
> > that I wrote - using cookies and a redirect to j_security_check. For a
> > demo, see http://demo.raibledesigns.com/appfuse.
> >
> > Matt
> >
> > On May 25, 2004, at 7:51 PM, Koji Sekiguchi wrote:
> >
> > > Yes, my question was "how to authenticate users as soon as they
> > > register".
> > > I think there must be API for it.
> > > Sorry for posting not clear question.
> > >
> > > Any ideas?
> > >
> > > Koji
> > >
> > >> -----Original Message-----
> > >> From: Patrick Willart [mailto:[EMAIL PROTECTED]
> > >> Sent: Wednesday, May 26, 2004 5:53 AM
> > >> To: Tomcat Users List
> > >> Subject: RE: API for authenticating user
> > >>
> > >>
> > >> I believe Koji wants to authenticate users as soon as they
> > >> register. I agree
> > >> with him that it's kind of silly to have the user first fill out all
> > >> his
> > >> user profile information to register as a new user to the site,
> > >> and then ask
> > >> him to log on. It would be nice if one is able to log on the user
> > >> automatically after registration.
> > >>
> > >> grts.
> > >>
> > >> Patrick
> > >>
> > >> -----Original Message-----
> > >> From: Yansheng Lin [mailto:[EMAIL PROTECTED]
> > >> Sent: Tuesday, May 25, 2004 1:15 PM
> > >> To: 'Tomcat Users List'
> > >> Subject: RE: API for authenticating user
> > >>
> > >>
> > >> Hi,
> > >>
> > >> Sorry, I might've misunderstood you. Are you saying that even
> > >> after a user
> > >> has loged in, they will still be prompted for log in information
> > >> if they try
> > >> to go to another page during the same sessions? That's weird...,
> > >> because
> > >> if you have your session set up right, tomcat will remember the
> > >> subsequent
> > >> requests from the same user.
> > >>
> > >> Or are you trying to remember the user for the following sessions as
> > >> well?
> > >> That would be platform-dependent since you will have to store user's
> > >> information locally on the client side.
> > >>
> > >> Can you clarify your question?
> > >>
> > >> Thanks
> > >>
> > >> Yan
> > >>
> > >> -----Original Message-----
> > >> From: Koji Sekiguchi [mailto:[EMAIL PROTECTED]
> > >> Sent: May 23, 2004 21:14
> > >> To: [EMAIL PROTECTED]
> > >> Subject: API for authenticating user
> > >>
> > >>
> > >> Hi,
> > >>
> > >> I'd like to know how to authenticate a new user when
> > >> he/she subscribe his/herself so that he/she can
> > >> avoid login procedure.
> > >>
> > >> I've successfully set up Form Authentication
> > >> and JDBC Realm on Tomcat 5.0.24. But now, new users
> > >> must visit login page to authenticate themselves
> > >> after subscribing. I'd like to reduce the login step
> > >> for subscribers if session continues.
> > >>
> > >> I think I have to use a couple of Tomcat API
> > >> and save principal information into the user session, right?
> > >>
> > >> regards,
> > >>
> > >> Koji
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
______________________________________________ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential. See: http://www.nextengine.com/confidentiality.php ______________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
