tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Everman <ever...@precedadesign.com>
Subject Re: Custom Authentification
Date Wed, 22 May 2002 15:53:09 GMT
I noticed this as well and it is an option.  However, the more I look at 
subclassing portions of Tomcat, the less I like this approach since its not 
portable - to other servers and likely to future versions of Tomcat.

What's really needed is an authenticate method in the Servlet API, but I 
don't see that changing this week :)

For myself, I've reduced the problem to one issue - creating a login and 
being logged in as a result.  I'll post that as another topic, since this 
thread was broader.

At 06:55 AM 5/22/2002, you wrote:
>Subject: Re: Custom Authentification
>From: "Adam Skobodzinski" <adamskobo@yahoo.com>
>  ===
>Hello Eric,
>I am not sure which classes that you looked at were final, but here is an
>excerpt from latest Tomcat (4.0.3b) changelog:
>---------------------
>Catalina New Features:
>---------------------
>
>[B1] Authenticator:
>      Make authenticator non-final so that they can be subclassed.
>
>Maybe upgrading to the newest version will solve your subclassing problem.
>I think there are a couple of features you have to implmenet yourself:
>automatic authentication after registration, password hints, and logon from
>a cookie.
>Adam
>
>
>"Eric Everman" <everman@precedadesign.com> wrote in message
>news:mailman.1021945620.860.jakarta_tomcat@basebeans.com...
> > Perhaps I should be more clear about what I am trying to accomplish (and
> > spell authentication correctly)
> >
> > I had originally created my own login/authenfication application.  It
> > allowed users to create profiles with a user name, password, a password
> > hint, and email addr.  Logged-in users are marked by a Principal object
> > (com.something.Principal) in their session.  The key reasons I had
> > originally gone in this direction were:
> > -To be able to give 'hints' and informative error messages to users who
>had
> > forgotten their passwords
> > -I wanted to be able to add my own functionality for handling auto-logins
> > via persistent cookies
> > -I wanted users who created a new profile to be logged-in as a result
> > (rather then be forced to login after creating their new profile).
> >
> > To work with security constraints, I created a small tag library for JSPs
> > that simply forwards requests to the login page if the user does not have
> > sufficient privileges.  A bit of a compromise since I can't define
>security
> > constraints in the web.xml, but it works rather easily.
> >
> > Everything was great until we decided we wanted to add a web forum -
> > Jive.  Jive, like thousands of other web apps, assumes that permissions
>are
> > handled via request.isUserInRole() and related methods.
> >
> > Of course, I'm not surprised that Jive doesn't use *my* authentication
> > system, but I was hoping that there was enough variation in authentication
> > strategies that largish applications would have a single point to allow
> > users to plug-in their own strategies.  So, if I can't easily modify Jive
> > to fit my current strategy, I'll have to modify my strategy to work within
> > or on top of the Servlet API authentication system.
> >
> > I've looked at sub-classing some of the Tomcat classes, but it looks like
> > some of the key ones are final - which leads me to think I still may be on
> > the wrong track.
> >
> > Any ideas?
> >
> >
> >
> > At 01:39 PM 5/20/2002, you wrote:
> > >I am trying to create a custom login / authentification system with the
> > >following requirements:
> > >
> > >-Tracks more info then just user name, password, and roles (ie email
>address)
> > >-Allow new users to fill in a new user form (with the extra info) and be
> > >logged in after successfully completing the form
> > >-Make the extra info available to Servlets & JSPs via a session object
> > >-Maintain compatibility with the Servlet API for authentification, namely
> > >that request.isUserInRole(), request.getPrincipal(), web-app defined
> > >security constrains work as expected
> > >
> > >Every solution I come up with seems to cross one of these lines.  I would
> > >appreciate any ideas you might have.
> > >
> > >Thanks,
> > >
> > >Eric Everman
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
><mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
><mailto:tomcat-user-help@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
><mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
><mailto:tomcat-user-help@jakarta.apache.org>
> >
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message