If you're rolling your own security management, I'd speak favorably for using the proxy pattern.
Take for example a simple user management area....CRUD operations on various users (get list of users, get user profile, add/edit/delete, etc). I used basically two classes to house the interactions w/ the database - a Factory class for returning User and User-related objects (ie User Roles, etc) and a Manager class for handling User persistance (ie add/edit/delete). The methods within these classes were exposed to the rest of the application via a SecurityHandler class. Then if you wanted to say, get a listing of Users...you'd instantiate this UserHandler object (passing into the constructor your own User object which was persisted in the session) and call 'userHandler.getUserList()'. The UserHandler would examine the User object which was passed to it at instantiation and examine the roles associated w/ the User to see whether it would throw a SecurityException or return the listing of Users. I'd advocate this pattern because you can decouple the biz logic (from the Factory and Manager classses) and security logic (in the Handler class) from the application flow (Struts). ----- Original Message ----- From: "Mike Dewhirst" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Friday, February 08, 2002 9:44 AM Subject: Controller and security > We are trying to come with a good security model in conjunction with Struts. > > I was thinking of calling a business class method to check the user's > permission for the requested mapping from within the Controller, but I'm > sure custom-modifying source code of a generic frame work is not exactly > best-practice. > > Any suggestions? > > PS Thanks to those who did for the advice with "actions and business logic"! > > > =********************************************************** > > If you are not the intended recipient, employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination or copying of this communication and its attachments is strictly prohibited. > > If you have received this communication and its attachments in error, please return the original message and attachments to the sender using the reply facility on e-mail. > > Internet communications are not secure and therefore the UCLES Group does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of the UCLES Group unless otherwise specifically stated. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses although this does not guarantee that this email is virus free. > > **********************************************************= > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
