As I understand you suggest to call a callback for every INSERT to DB, the callback will get the entity object and check against the DB to verify that the returned object really belongs to the logged in user? But what about a SELECT query that returns 100 objects? The solution should be tied to the DB layer, because in this case for performance reasons I'd like to make a JOIN with the Users and the Comments table in the SELECT query that will make sure that the returned comments will belong only to the logged in user.
I hope you understand me, because my use case became a little bit complicated without any query examples provided. Thanks, Edi. On Wed, May 14, 2014 at 2:57 PM, Marco Pivetta <[email protected]> wrote: > I wouldn't tie in the framework for row-level security, as it is likely > going to follow your own rules for loading/saving data. > > I mean, you can, but you could really just fire events on read/writes and > let a callback handle them and eventually throw exceptions > (UnauthorizedException, for example) in case of illegal access. > > I wrote a few firewall components for ZF2 and I think that security that > is so near to the core of your application shouldn't rely on framework > functionality if possible, but instead on your own security service. > > Something as simple as: > > class MySercurityCallback > { > public function __construct(AuthorizationService $auth) > { > $this->auth = $auth; > } > > public function checkGrants($entity) > { > if (! $this->auth->isGranted($entity)) { > throw new UnauthorizedException('Can\'t touch this!'); > } > } > > AuthorizationService is up to you, and it could even use a framework if > you wanted. > > Then, in your service layer, you'd just either call this directly or use > it as a callback in an EventManager/EventDispatcher. > > You could use the doctrine internal event dispatcher, but I don't think it > is good to tie business logic into the persistence process, as it becomes > subtle to deal with. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On 14 May 2014 13:02, 'Jasper N. Brouwer' via doctrine-user < > [email protected]> wrote: > >> ACLs not only function on a class level, but also on a individual entity >> level. You can find more info on this here: >> >> http://symfony.com/doc/current/cookbook/security/acl.html >> >> -- >> Jasper N. Brouwer >> (@jaspernbrouwer) >> >> >> On 14 May 2014 at 11:35:35, Edi Buslovich ([email protected]) wrote: >> > These classes provide class level and action level (edit, insert) >> > permissions, what I need is per-record permissions. >> > Thanks for the references, I'll ask in the symfony's mailing list, maybe >> > they have more specific solutions. >> > >> > Thanks, >> > Edi. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "doctrine-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/doctrine-user. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "doctrine-user" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/doctrine-user/EqHFuKZUblw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/doctrine-user. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
