On Tue, 12 Jun 2001, Abraham Kang wrote:
> Hi Craig,
>
> Thanks for the clarification.
>
> I was wondering if you knew of any other way to do pre-processing
> before being authenticated and post-processing after authentication
> when using the form based authentication.
>
> Would filters work here?
>
Maybe.
The reason that the spec is so specific about "j_security_check" is to
provide containers lots of leeway in *how* they implement form based login
-- as long as they conform to the requirements that are listed, they can
do what they want. For example, Tomcat 4 recognizes the
"j_security_check" as the clue it needs to replay the *original* request,
so that the "j_security_check" request itself never goes through the
filter chain.
You'd be a lot better off in a servlet 2.3 environment by using
application event listeners to notice session creations, so that you can
(for example) mark the session as needing some special handling on the
next incoming request -- that, of course, being the only time you know
who the authenticated user really is. Of course, in a nice MVC framework
(like Struts :-), the actual processing to be performed can be easily
delegated to the controller servlet.
> Sincerely,
> Abraham
>
Craig McClanahan
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 12, 2001 4:59 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: Form-based Authentication
> >
> >
> >
> >
> > On Tue, 12 Jun 2001, Abraham Kang wrote:
> >
> > > RE: Form-based AuthenticationHi Jason,
> > >
> > > I should have been clearer.
> > >
> > > The only time that you do not want the login-form to specify
> > > "j_security_check" as its action is when you want to do some special
> > > preprocessing before the user is authenticated. By forwarding
> > to a servlet
> > > (I haven't tried this with an Action but it should work) you can do your
> > > preprocessing in the servlet and then do a
> > requestDispatcher.forward( ) to
> > > j_security_check. This will allow you to do pre-processing and take
> > > advantage of the containers authentication realm.
> > >
> >
> > WARNING: Although it might be supported by some containers, you are *not*
> > guaranteed by the servlet spec that you can portably play that sort of a
> > game. The spec clearly states that the form login page *must* have an
> > action of "j_security_check". (I haven't tried it, but I'm pretty sure
> > your technique would not work on Tomcat.)
> >
> > > My guess is you are currently doing authentication against
> > a database
> > > table. If you are using WebLogic you can use the DBMSRealm. This will
> > > probably mean you will need to add some tables to support the roles in
> > > WebLogic but now you don't need the authentication code in your actions.
> > > The container manages access to protected resources. You don't
> > have to have
> > > any scriptlets at the top of your pages as long as the regular
> > expression in
> > > the <url-pattern> of the <security-constraint> element of your web.xml
> > > matches all of your protected resources.
> > >
> >
> > Tomcat supports a similar mechanism -- you can configure lookup of users
> > in a flatfile, in a database, or in a directory server. Each container
> > will provide it's own mechanisms for defining how and where users and
> > roles can be stored.
> >
> > > --Abraham
> >
> > Craig McClanahan
> >
> >
>
>
