| Problem 3: Protecting the application from logged-in users who are | spoofing form parameters | | [...] | | However, we don't want to violate the DRY principle: if there are | multiple places where a given Entity can be selected for editing, we | would have to add this check in each place.
That's what I've done in my application: For example before an object is written back to the database a HiveMind SecurityService checks if the current user is allowed to execute the requested operation (edit, delete, ...) on the object with the given id. If a AOP solution was possible I'd prefer that one because as you mentioned I had to add the security check to every page that handles objects which is not very clean (but not as bad as you might think IMHO as the code is still modular due to the fact that I'm using a HiveMind service). Kind regards, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
