1

im starting to implement some security features in my application. When initially trying to implement some ACL I came acress two questions I could not figure out:

  1. Where to implement the setting of acl I could do it in the controller action where my entities are created or on the entity itself with lifecyclecallbacks. For example I have a Group Entity which holds some Userentities. It is easier to set the view or edit access on a lifecyclecallback for all group entities. I would prefer to make my controller as slim as possible. Or is this a bad approach? I would need the security container in my entity. What is your approach to this?
  2. How to check for related entities: Extending my previous example, I have a Group and this group can hold some appointments. In my actions where the appointments are shown or edited, I only want to check for the group. This is mainly for using the "view" rights. Meaning if someone is in the Group which holds the appointment, the person should also be able to view the appointment. I would like to implement this with JMSExtraSecurityBundle and SecureParam, but I have no Idea how to do that.
Elnur Abdurrakhimov
  • 44,533
  • 10
  • 148
  • 133
m0c
  • 2,180
  • 26
  • 45
  • 1
    You better use your entity just for database data access/modification. If you wish your controller be slim as possible, place acl code to some handler and call it from controller. [Single responsibility principle][1] told us that "a class or module should have one, and only one, reason to change". Putting some logic in your model will break this very useful and important principle. Your second question I can not understand, sorry. [1] http://en.wikipedia.org/wiki/Single_responsibility_principle – ryabenko-pro Sep 23 '12 at 22:22
  • Okay, I will check out using a Handler for that. My second question is about "inheriting" acl settings. For example I don't need acl rules on my appointment entity, since every appointment entity is related to ONE group entity. And the group entity has all acl information I need. So for my case ONLY the group entity determines wether an user can view/change an appointment. And I would like to implement this behaviour with annotations (JMSExtraSecurity:@SecureParam). I hope it is a little bit clearer now. – m0c Sep 26 '12 at 07:58
  • There are several actions that change the users of an group: "leaveGroup", "createGrouP", "joinGroup", "inviteToGroup", etc. Since these are several actions I dont wan't to put it on the controller or a handler. There might also be the chance of more actions. I would like to forget about updating acl when it is initially implemented. This is the reason I would like to add the logic to the domain model. Then I could modify my entity from whereever I want, without caring for ACL. Would a Eventlistener on the prepersist be a solution? So the logic would be in an ACLEventlistener? – m0c Nov 01 '12 at 11:58

0 Answers0