Thanks for the answer, I still think that ACL is maybe a to complex solution, meaning that I won't ever need to extended the use case like you said.
I will have instead a User having various data such as reservations, contacts, mails, etc. With both approaches I think there would be quite some work to implement security. If I don't use ACL i would need to write code in every business method to get the logged user, get for example the reservation object for the reservation.id (or person.id) passed, check if that reservation belongs to the user and eventually in case deny access. This need to be done for every call to an editReservation, deleteReservation, editContact, editWhatever, etc. Using ACL, which I am not so familiar with, I understand I still have to create an ACL for my domain objects and give access and implement a pretty complex infrastructure I was thinking if a better approach could be passing around in each and every request the user id related to the action I am handling (such as the user id for the reservation.id to edit or for the contact id, and so on). I would then have a filter or something always checking that id against the current user id, denying access if they don't match. In this way I wouldn't have to write custom code in every method. Or again, I guess i could be missing something, because I would think that this kind of security need is required by most web apps with authentication and there could be maybe a more standard solution. Michael Horwitz <[EMAIL PROTECTED]> wrote: It sounds as if ACL may be the best approach for you given that you want to control access to objects owned by the user object rather than the user object itself. It is worth noting that both approaches would work. Using ACL you could then extend the use case to users to edit each other's contacts if the owning user has granted them permission. Mike. On 4/26/07, frantuma <[EMAIL PROTECTED]> wrote: Hi, I have some troubles understanding how the following scenario is to be handled in appfuse: I believe the scenario is a typical need of a web app, and I was wondering what is the best way to handle it. Let's say that (from Acegi reference..): Imagine you're designing an application for a pet clinic. There will be two main groups of users of your Spring-based application: staff of the pet clinic, as well as the pet clinic's customers. The staff will have access to all of the data, whilst your customers will only be able to see their own customer records. Which is the best way to achieve globally the above goal, specifically: your customers will only be able to see their own customer records. Using the appfuse Person tutorial as an example, I need that a call to PersonAction.list() populates its persons list only with the persons related to the currently logged in user, and to allow editing of a given person only to the user "owning" this person (a person would have a user field, meaning that a user has a list of Persons; persons could actually be the list of contacts of the user). In the appfuse tutorial personList.jsp creates links to editPerson.html passing person.id as parameter. PersonAction.edit() simply loads the property corresponding to the id, with acegi configuration taking care of authorization making sure the logged in user has ADMIN or USER roles. But it seems to me that if someone logs in as userA an then sends a GET to editPerson.html with any personId, there is no mechanism implemented which checks that the person.id is "owned" by userA and thus can be edited by him. Without this mechanism userA can get access to all persons and generally to data of all other users. To avoid this - and to have personList display all person if the user is ADMIN and only persons belonging to the user if the user has only role USER - I think I understand that ACEGI suggests either writing custom code to enforce security by checking every time SecurityContextHolder.getContext().getAuthentication().getPrincipal(), or using ACL mechanisms. Is there any suggested best way to achieve the above? or do I miss something... Thanks Francesco -- View this message in context: http://www.nabble.com/Sort-of-Acegi-domain-object-security-tf3652387s2369.html#a10202904 Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
