We actually implemented our own ACL system. We used symfony's builtin user
session management features (i.e. $this0>getUser()->setAuthenticated(true)
etc) but not any of sfGuards special functionality because our needs were
too complex.
We also send an authentication request to our ACL server to confirm the user
CAN login and if he can return a list of his permitted module/action
pairings.
Once the calling app has this list back from the rest request we persist it
into the users session ($this->getUser()->setAttribute('acl', $acl_array);
). Then we created a filter that on each request for a specific
module/action will compare it to the users ACL list in session and if
matches will then allow execution to continue.
In addition we implemented a post filter (within the same filter) that
searches for specific HTML comment strings in order to control what the user
is allowed to SEE on the rendered page. No point in showing a link to a
module/action that he is not allowed to perform. Our view would like this
for example:
<!-- aclopen module_name/action_name -->
<?php echo link_to('Link','module_name/action_name'); ?>
<!-- aclclose module_name/action_name -->
So the post filter will see the line starting with "<!-- aclopen" and know
an inline acl check needs to be performed. It will then use the module_name
and action_name following to determine what acl match is required for the
user to view the content and decide whether to display or not to display the
following lines of code (the link). Once it reaches the acl_close for the
same module_name and action_name it will stop filtering for that acl check.
In short, we pre-filter the action/module based on his acl list. This acts
as a "fallback" in case he does try to access links, buttons, etc that would
let him do stuff hes not allowed to. We also post filter the response to
remove chunks of the view that he should not see based on his acl.
For us, trying to integrate into an existing plugin was too difficult and so
did it from scratch. The only way you will know for yourself whether you
need to use sfGuard or not is see what features sfGuard provides vs what you
need and compare from there.
On Mon, Aug 16, 2010 at 5:31 PM, catchamonkey <ch...@sedlmayr.co.uk> wrote:
> Hi all,
>
> What are your thoughts on implementing an existing ACL which is
> accessed through an API into symfony 1.4?
> I would ideally like to use sfGuard and replace the main elements of
> signin, signout and any permission calls et al.
>
> Do you think it would be best to start from scratch or build on top of
> sfGuard(Doctrine)
>
>
> Regards,
> Chris (catchamonkey)
>
> --
> 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<symfony-users%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/symfony-users?hl=en
>
--
Gareth McCumskey
http://garethmccumskey.blogspot.com
twitter: @garethmcc
--
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
