As I said, this is a bad idea nonetheless... It might be working now, but it will only cause you problems further down the road. It's better to go with the proper solution I mentioned before.
Kind regards, Johannes On Mon, Feb 7, 2011 at 10:05 PM, phil0 <fis...@gmail.com> wrote: > Ok, what I've done now is: > > I created a new DI service into which the SecurityContext is injected. > This service has a method called vote() that takes the same parameters as > SecurityContext::vote(), but this method calls SecurityContext::vote() with > the admin role. If the role doesn't have access, SecurityContext::vote() is > called again, this time with the objects for the ACL check. > > A bit of a workaround but it seems to be working. > > -- > 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
