Hi Mark,
Thanks for your answer!
When you follow the conversation right from the beginning, you will
see, that I definitly KNOW that controller/actions/id access does not
help me and that I therefore want to use your proposed schema of
models/records to protect my content.
However, what confused me as a beginner was, that in all the official
documentation there where only examples of "the easy way".
My intention was to ask for the "best practice" for providing access
on a model/record level.
I already implemented the ACO tree as you proposed (I have a "models"
hive where all records get its entry).
As Mark explained, I have to do the permission check manually. Fine, I
can do this using $this->Acl->check() Doing this in the controller
would work, but seems to be quite complicate as I do combined queries
from different models. So I get a result of :
result = array (
[model0] => array (
[field0] => value,
[field1] => value,
...),
[model2] => array (...)
[model3] => array (...)
)
now, if the user has i.e. read permissions for model2 but not for
model0 and model3, how would I do that? Check manually all entries and
delete the ones he does not have permissons on?
Is there a "Best Practice" how to deal with that?
Thanks,
bye
me.
On Nov 20, 5:28 am, mark_story <[EMAIL PROTECTED]> wrote:
> This can be done with the ACL but you need to do the check manually.
>
> It may seem like a good idea to have an ACL tree that looks like
>
> controller/action/id
>
> but that is setting yourself up for an epic fail. If you ever need to
> add an action you need to copy all the record nodes and set new
> perms. If you make a record in a controller with 10 actions, you now
> need 10 records. It gets insane very quickly. Some quick math also
> shows this is the wrong approach.
>
> 150 records x 8 actions x 10 controllers = 12000 ACO elements.
>
> This is a very conservative estimate, as most applications have far
> greater amounts of data than. A further indication of a wrong
> approach is that this system and any proposed changes to the
> AuthComponent fall short under the following circumstances:
>
> * when an action needs to edit more than one row
> * when an action needs to display more than one row
> * when an action needs to work on a record and its related records.
>
> There are probably more that I didn't think of but in all cases
> controller/action/id is a recipe for disaster.
>
> A better approach in my opinion is to keep your controller/action
> perms separate from your model record permissions, and do the check
> manually. If you application is sophisticated enough to require these
> advanced permission settings, it can stomach a few extra method calls.
> I would use a tree like
>
> app
> -- controllers
> ---- posts
> ------ index
> ------ add
> ------ edit
> ---- comments
> ------- index
> ------- edit
> ------- view
> -- models
> ---- post
> ------ 1
> ------ 2
> ---- comment
> ------- 1
> ------- 2
>
> and so on. Another option is to use the idea of 'roles' for all your
> access control and assign permissions with those.
>
> Sorry if I ranted a bit there, but I'm tired of people belly aching
> that controller/action/id doesn't work when it is obviously the
> totally wrong solution for the problem. And anyone who thinks it is a
> great idea should go for it, and report back in a year or so after
> their app runs into scaling issues because the ACL is ridiculously
> complicated and impossible to deal with.
>
> -Mark
>
> On Nov 19, 9:55 am, eMarcus <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I want to use the ACL component to control access of users to model
> > data.
>
> > I built up AROs, ACOs and permissions so far.
>
> > 1.) does the ACL component automatically check if a user has an UPDATE
> > right on save operations?
> > 2.) if not, where would be the best place to perform that check? (in a
> > callback function in the model itself, in the controller?)
>
> > Thanks,
>
> > bye
> > me.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
