Hi All, Another option is to use JASS, this way you can plug in a portable custom login module, its supported by WAS, WLS, HPAS (that I know of). As already mentioned form base security is a good option 'some times'.
Jon. -----Original Message----- From: David Cypers [mailto:[EMAIL PROTECTED]] Sent: 30 April 2002 08:25 To: Struts Users Mailing List Subject: RE: Form based security Hi there, I recently implemented access restrictions (and login) through use of the servlet 2.3 filter API. In that filter, you can write anything you want, so it's also possible to hook up to an existing dBase. (that's exactly what I did though) If you work following the principles of the MVC model (one access point, being the controller), it should be very simple to implement restrictions for each page. You could also map your access levels for certain pages in separate xml files. Just create a filter which checks the request parameters, session , etc, and compares this data to the defined access levels. If a user is restricted, the filter can break the chain even before the controller is reached, and eg. redirect the user to a login or error page. Imho servlet filters are really powerfull stuff. Hope this helps you on the way, Regards D.C. -----Original Message----- From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] Sent: maandag 29 april 2002 22:39 To: Struts Users Mailing List Subject: RE: Form based security 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]> upco -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
