Yes, I thought about that. I've been avoiding that approach, but I think now it could help. That way I wouldn't need to delete and insert the ACE again. I could update it and that's it. It's a little bit more of work but I'll give it a try. I'll get back with comments about it. And I'll try to reproduce the mentioned issue in a test too.
Thanks. 2011/4/9 Johannes Schmitt <schmitt...@gmail.com> > I think even if it is a bit more work when changing permissions, you should > definitely look into cumulative permissions since this will increase the > performance of your application. It should be sufficient to have one ACE > with all granting, and one ACE with all denying permissions for each > security identity. > > Only changing the granting flag might cause problems in combination with > the granting strategy, and I don't see the use case for it right now. > > Kind regards, > Johannes > > > > On Fri, Apr 8, 2011 at 10:35 PM, Gustavo Adrian < > comfortablynum...@gmail.com> wrote: > >> Of course. I'll try to reproduce the issue in a test. In the meantime I >> want to clarify that I don't use cumulative permissions, because I need to >> configure for each permission if it's an ALLOW or DENY entry, and it's >> easier this way. Taking this fact into account, If I could update the >> "granting" property of an ACE, I'd just update the existing ACE instead of >> deleting and inserting it on the ACL. I've noticed that you can update a >> field ACE passing the following properties to the "updateObjectFieldAce" >> method of the Acl class: >> >> $index, $field, $mask, $strategy = null >> >> Could it be an issue if we add an additional property ($granting) to >> update the granting property of the ACE or this could be a problem at some >> point of the update? if it wouldn't be an issue I could try to add the >> functionality, but first I'd like to be sure if there's a technical reason >> to not update the $granting property of an ACE. >> >> >> Thanks! >> >> Best regards. >> >> 2011/4/8 Johannes Schmitt <schmitt...@gmail.com> >> >>> It would be nice if you can provide a failing test case in >>> MutableAclProviderTest, otherwise just create a ticket, and I'll take a look >>> at it. >>> >>> Johannes >>> >>> >>> On Fri, Apr 8, 2011 at 9:43 PM, Gustavo Adrian < >>> comfortablynum...@gmail.com> wrote: >>> >>>> MySQL logs show: >>>> >>>> 2940 Query START TRANSACTION >>>> 2940 Query UPDATE acl_entries SET ace_order = 4 WHERE id = 464 >>>> 2940 Query UPDATE acl_entries SET ace_order = 3 WHERE id = 465 >>>> 2940 Query UPDATE acl_entries SET ace_order = 3 WHERE id = 466 >>>> 2940 Query UPDATE acl_entries SET ace_order = 1 WHERE id = 479 >>>> 2940 Query rollback >>>> >>>> >>>> It first changes ace_order's, so if I deleted the entry with ace_order = >>>> 1, at the time of synchronizing changes in the DB it first updates >>>> ace_order >>>> fields, so the ACE I deleted is still there (with ace_order = 1 too). This >>>> is, of course, for ACEs that are affected for the same unique index, which >>>> have this fields: class_id, object_identity_id, field_name and ace_order. >>>> >>>> >>>> Thanks. >>>> >>>> 2011/4/8 Gustavo Adrian <comfortablynum...@gmail.com> >>>> >>>>> Hi all, >>>>> >>>>> During the update process of fields ACEs I'm getting this error: >>>>> >>>>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry >>>>> '12-1106-entityTypeFriendly-1' for key >>>>> 'UNIQ_46C8B806EA000B103D9AB4A64DEF17BCE4289BF4' >>>>> >>>>> I explain what I'm doing: As I allow to change the type of granting of >>>>> the permission (allow or deny), and I didn't find a way to update the >>>>> granting property of an ACE with acl methods like "updateObjectFieldACE" >>>>> or >>>>> the like, I'm just deleting the ACE and inserting it again on the ACL with >>>>> the new value for the granting property. I do all this stuff for every >>>>> field >>>>> and, at the end, I update the ACL with $aclProvider->updateACL($acl); . >>>>> Could this way of updating the granting property of an ACE bring this >>>>> exception? >>>>> >>>>> I'm looking at the MutableAclProvider and I see that the >>>>> updateXXXProperty methods first insert new ACEs and finally delete old >>>>> ACEs >>>>> (the ones which were deleted from the ACL). Could this mean that, as I >>>>> deleted and inserted a new ACE from an ACL at the same time, at the moment >>>>> of the update on the DB it first try to insert the new ACE with the same >>>>> ace_order as the one that is going to be deleted? it's just a guess. I'm >>>>> trying to trace the error so I can give further details. >>>>> >>>>> Is there a way to update the granting property of an ACE so I can >>>>> update the ACE instead of deleting it an reinserting it again? >>>>> >>>>> >>>>> >>>>> Thanks in advance! >>>>> >>>> >>>> -- >>>> If you want to report a vulnerability issue on symfony, please send it >>>> to security at symfony-project.com >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "symfony users" group. >>>> To post to this group, send email to symfony-users@googlegroups.com >>>> To unsubscribe from this group, send email to >>>> symfony-users+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/symfony-users?hl=en >>>> >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send it to >>> security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony users" group. >>> To post to this group, send email to symfony-users@googlegroups.com >>> To unsubscribe from this group, send email to >>> symfony-users+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-users?hl=en >>> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to symfony-users@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-users+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
