Subject: Re: Form based security From: Vic C <[EMAIL PROTECTED]> === I just had a development meeting here on the topic. Use container security. In (base) action do a getRemoteUser(). Based on it, (and isUserInRole) create a sessionUserBean that has other info I get from DB. Anyway, I will take this path.
Vic Phase Web and Multimedia wrote: > I concur! I think container based security is the biggest pain in the #$!. I > am writing a (hack) for multiple login pages/auto-login/etc... and it is > taking way too much time. When the promise that container based security > would be easier in servlet 2.3 I was exceited. But, it seems now like we > were lied to. Does anyone know if the future holds hooks to allow for custom > security logins? > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -----Original Message----- > From: Tero P Paananen [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 2:26 PM > To: Struts Users Mailing List > Subject: RE: Form based security > > > >>Im in the process of re-engineering an application and I am >>focusing on >>how to implement the security. The current application uses a >>combination of security checks within the action classes and >>jsp custom >>tags based upon a user session object. After reading more about the >>form-based security provided by J2EE compliant app servers >>however, I am >>thinking that server based security is a more robust solution. Im >>curious how other developers are approaching security. If you >>are using >>application server managed security, have you run into any >>limitations, >>or has it been a better approach than a custom solution? Thanks, > > > Application server managed security is a very good > solution, IF your application doesn't require running > business logic as part of the login process. > > If your login process requires checking this and that > from a datasource and/or do conditional processing > based on the "state" of the user, the application, > a third party or any other system, then application > server managed security is going to be a problem for > you. > > The reason is that the servlet specification doesn't > require application server vendors to provide any > means to hook up a custom login process into the > application server managed security login. > > It can be done, but the solutions are more like > hacks than solid programming. Furthermore any > solution you will come up with is most likely > going to be non-portable between app servers. > > We've recently implemented form based security with > custom login using WebSphere (and Tomcat) and the > solution we came up with is less than optimal from > security, MVC architectural and code maintainability > point of view. > > In summary: if you do NOT have a custom login process, > you're cool. If you do, make sure you have a neverending > supply of painkillers at hand. You'll need them. > > -TPP > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
