tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakarta Tomcat Newsgroup (@Basebeans.com) <jakarta-...@basebeans.com>
Subject Re: Custom Authentification
Date Wed, 22 May 2002 11:55:01 GMT
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>


Mime
View raw message