Hi Jon,
I know that WebLogic gets rid of these after authentication.
--Abraham
> -----Original Message-----
> From: Jon.Ridgway [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 13, 2001 1:51 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Form-based Authentication
>
>
> Hi All,
>
> Form based auth is something that I have just been looking at, so
> I thought
> I'd add my two pennies worth.
>
> My login form is using struts html, bean and template tags (no html:form)
> and all appears ok. My template has an adapted version of the
> checkLogin tag
> provided with the struts-example. My adapted version just checks
> that a user
> attribute is in the session and creates one if it is not using the
> j_username and j_password to look the users' details up in my db.
>
> Question: can I be sure that *all* containers will put a j_username and
> j_password attribute in the session, like tomcat does?
>
> Jon.
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 13 June 2001 02:05
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Form-based Authentication
>
>
>
> 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
> > >
> > >
> >
> >
>
