As I told in this thread before, what I want to do is
authenticating users as soon as they register themselves.
Currently new users have to (1) visit subscribing page to subscribe
and then (2) visit login page and input user name and password again.
I want to avoid (2) step for new users.
And I found the Tomcat API that seems to be used
to memorize user principal into session. But I faced class loader problem.
And yes, I agree with Justin, I don't want to move catalina.jar
from server/lib to common/lib.
So, now to solve this, I tried next option, that is, I tried
RequestDispatcher.include()
method in order to call j_security_check action as follows (in my struts
action):
// prior to the follwowing code, username, password and
// role have been successfully saved into JDBCRealm
RequestDispatcher dispatcher =
getServlet().getServletContext().getRequestDispatcher(
"/j_security_check" );
request.setAttribute( "j_username", username );
request.setAttribute( "j_password", password );
dispatcher.include( request, response );
But this didn't solve the issue. After registering user and running the
above code,
users who try to visit secured page forced to move to login form and are
asked
to input username and password.
What am I wrong?
regards,
Koji
> -----Original Message-----
> From: Justin Ruthenbeck [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 28, 2004 12:35 PM
> To: Tomcat Users List
> Subject: RE: API for authenticating user
>
>
>
> 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(Re
questProces
> >sor.java:484)
> >
> >org.apache.struts.action.RequestProcessor.process(RequestProcesso
r.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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
