I've been dealing with this same problem. All though Form base authentication is session based the realm has no accessibility to the session object. There are also no events that tell when the session is first created only when objects are bound/unbound to the session. The isNew function is on New on the logon page if using FORM auth.
One thing I've played with is creating my own principal that that extends org.apache.catalina.realm.GenericPrincipal the principal is available from HttpServletRequest.getUserPrincipal() but this is still not a complete solution since it is still disjointed from the session. I haven't looked at struts or turbine, I'm still trying to keep my head above water with tomcat and jboss... I'm using jsp pages so apparently turbine is out I would assume that we are not the only one's with this problem. Basically a secure app that when a user logs in needs to have some state data stored at the session. I figured that using the built-in security mechanism would be a more elegant solution but I'm finding that I have to do a lot of work arounds to get it to fit into my paradigm. if the Authenticator functionality was configurable via the web.xml or server.xml this would fix our problems. here's what I found on them but still not a clean solution having to muck with internal config files... http://mikal.org/interests/java/tomcat/archive/view?mesg=56125 if the forms Auth had one more configuration <form-success-page> this would also solve our problem centralizing all initialization. so much for the Rant. (I hope some of the Tomcat Developers watch this mail list...) -----Original Message----- From: Benjamin Drasin [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: Re: Do I have to use j_security_check to authenticate? Thanks Rick, Some of my business code has to run before authentication takes place (the details are very specific to my application). Right now the code works like this, all in one servlet: 1)pre-authentication code 2)if ok to proceed 3) authentication code 4) post-authentication code (initialize the session) I might be able to stitch together something like this: 1) request goes for the "initialize the session" page, which is protected. 2) the user is not authenticated, so the go to my login form, which 3) submits to my own URL, do the pre-processing if ok to proceed forward to j_security_check 4) j_security_check authenticates, and forwards to the URL requested in step 1. 5) my page initializes the session. This strikes me as _awfully_ hacky. What I really want is to be able to explicitly authenticate the user from within my servlet code...is there really no way to do this? It seems to me like something that lots of people would want. It would allow me to keep all of my login code organized in a logical manner, rather than having to dance around the servlet container. Thanks in advance, Ben Drasin >From: "Rick Fincher" <[EMAIL PROTECTED]> >Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]> >To: "Tomcat Users List" <[EMAIL PROTECTED]> >Subject: Re: Do I have to use j_security_check to authenticate? >Date: Mon, 22 Apr 2002 18:36:13 -0400 > >Hi Ben, > >Someone else today had similar questions so you might want to check for the >subject "initializing Session state during realm login." > >This was in Tomcat 4.0.x which has this built in. > >If you use FORM level security you submit your own jsp page as the login >page and another as the page to run if login fails. After login Tomcat >passes control to your main page. When I converted some stuff like this I >basically just stripped out the database lookup stuff and and took the >login >page front end (HTML stuff) and put it in a new file. That left the rest >of >my init stuff intact in the old login page. > >You can request info like the username, role etc from the request object >with it's various methods. > >It is actually very nice because Tomcat now handles that for you and you >can >take most or all of the security validation stuff out of your pages. Like >you say this makes your project something you can deploy with Tomcat or a >full blown J2EE server without changes. > >One snag as the other fellow found out is that you lose a little control of >what happens when a session times out. You get bounced out of the realm so >you have to figure out how to deal with that. > >Rick > > > Hello all- > > > > I have a servlet based application running on Tomcat 3.2. It uses a > > homespun security system which I would like to replace with standard >J2EE > > security. However, when the user logs in there are a number of >server-side > > tasks which have to be performed both before and after authentication >takes > > place, and which logically and functionally are all part of the login > > process. > > > > Therefore it is a problem for me that, as best I can tell from availible > > documentation, all authentication is done through the magic URL > > "/j_security_check" which is opaquely handled by the application server. > > > > I have seen some suggestions on newsgroups that I should hack my way >around > > this by having my own servlet code forward to /j_security_check after >doing > > my own processing, but > > 1)this is not really what I want because some of the work I have to do > > should not take place until after authentication, and > > 2)that seems like a collosal hack that might have ramifications I don't >know > > about. > > > > What I really want is a server-side method like authenticate(username, > > password) which would be functionally the same as submitting to > > /j_security_check. Does any such thing exist, and where can I find out > > about it? If not, can anyone suggest an alternative? > > > > Thanks in advance, > > > > Ben Drasin > > > >-- >To unsubscribe: <mailto:[EMAIL PROTECTED]> >For additional commands: <mailto:[EMAIL PROTECTED]> >Troubles with the list: <mailto:[EMAIL PROTECTED]> > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
