I think you may need to question if everyone needs to be able to open edit,
or if there should be more than just a generic edit. ACL takes care of
that. You may need to make your controller methods smaller and have
smaller pages, because overly large pages can definitely complicate and
confuse users and developers.
When you add layers of complexity, often you'll have exponential more code.
Types of admins can be different prefixes. Organization Admin, User
Admin, etc. Just some things to consider.
I'm in a similar boat.
On Mon, May 7, 2012 at 12:03 PM, bs28723 <
bill.sto...@boosterwebsolutions.com> wrote:
> Thom,
> Thanks for taking the time to respond. This would be a good time to fix
> some things in my application if needed. So, I appreciate your help and
> suggestions.
>
> Based on your feedback, I feel like I need take your lead and explore a
> few things. These are topics I have been wondering about.
>
> Based on your comments, I still could use your advise on a few things.
> First, I simplified my question before posting the first time. It is
> actually much more complicated, so let me explain.
>
> To answer your question, at a high level it is to restrict who can edit
> what. But unfortunately it is not that simple. I have looked at the
> prefix routing, but I am not sure this works for me as I will try to
> explain.
>
> First, I have
>
> Organization
> $hasMany = array( "OrganizationRoles", "MemberRelationship");
> $belongsTo = array("User");
>
> OrganizationsRole
> $hasMany = array("OrganizationPermissions", "MemberRelationship");
> $belongsTo = array("Organization");
>
> OrganizationPermission
> $belongsTo = array("OrganizationsRole");
>
> MemberRelationship
> $belongsTo = array("OrganizationRole", "Organization", "User");
>
> User
> $hasMany = array("Organization", "MemberRelationship"
>
> Each Organization has roles. There are 3 default roles per Organization
> (Admin, Owner, member), but an Owner or Admin can create more roles as
> needed for their Organizations, thus dynamic roles.
> A User can belong to Multiple Organizations.
> A User can have a different Role depending on the organization. Owner in
> Org1. member in Org2. no relationship with Org 3.
> The MemberRelationship Table is a join table that links Users to
> Organizations and Roles.
>
> So, I felt prefixes would not work, because 1) an "admin" prefix is
> different depending on the Org. 2) there could be Prefixes created on the
> fly. 3) it seemed complicated to had all these different prefixes that do
> basically the same things, just the Org may be different.
>
> So, I have gone more toward the authorization route and have created a
> Authorization component. I also plan to add the security component to
> handle the CSRF stuff, but that is not implemented yet. What I have
> implemented is CRUD permissions per role per organization for different
> pieces of information.
>
> My issue is that in the view I need to use $this->Form->input(); to
> allow the user to update the field.
> So, while the controller has gotten authorization that this user has
> either Read or Update permission for some or all of the data, The question
> is
>
> Is it better to
> 1) send all the data & permissions to the view and let it decide when to
> use input() or just display the text?
> or
> 2) filter the data and send field lists to the view or which are display
> only and which allow input?
>
> I have started down the #1 path, but this is seeming complicated with all
> the views and if things change, I could have 20 views to update. So, I am
> thinking that option #2 may be a better long term solution. I think I can
> centralize more stuff in the controller. I will just have to make the
> views handle display fields and input fields.
>
> Thoughts? Suggestions?
>
>
> On 5/7/2012 9:18 AM, Thom Seddon [via CakePHP] wrote:
>
> Hi Bill,
>
> Not exactly sure if you just asking how to hide specific elements or
> restrict who can edit what.
>
> For the former, I would suggest you filter the list in the controller to
> create separate "editable" "viewable" arrays that you can use in the
> controller. This would both remove your repeated logic (that's what
> the controllers is for!) and would also therefore mean changes wouldn't
> have to be repeated (or forgotten about) in each instance in each view....
>
> For the latter, In my opinion this is probably best solved with separate
> views and controller methods for each role, after all it is this type
> of privilege restriction for which prefix routing was primarily designed
> for<http://book.cakephp.org/2.0/en/development/routing.html#prefix-routing>.
>
>
> Whilst your current solution restricts what form fields are visible, it
> is still trivial for a user (of any privilege) to create requests you are
> trying to restrict, for example posting to "/users/delete/1", the requests
> are still possible, you are just hiding them. It if for this reason that it
> would be necessary to perform the same type of role filtering in the
> controller, are you also doing this? (Note: The CSRF protection that is
> optionally implemented by the security component would black hole requests
> such as in my example, relying on this would require you to ensure all
> controllers are using the security component and that anything you are
> restricting requires a POST/PUT/DELETE (Read: not GET))
>
> By the time you have typed out all this access filtering, both view and
> controller, and made sure security component is always included in every
> controller from now to the end of time, you may well find that the
> duplication required by prefix routing may well be a justifiable
> option. Additionally, I would probably say this approach would cultivate a
> more secure and restrictive approach to your app design which is likely to
> lead to a more robust setup in the end.
>
> Hope this answers your question.
>
> Thom
>
>
>
>
> On Monday, 7 May 2012 00:58:42 UTC+1, bs28723 wrote:
>>
>> There should be a better way than what I am doing right now......
>>
>> I have a set of 3 default Roles (Owner, Admin, Member). users can add,
>> delete, modify the Roles, except the 3 Default Roles.
>>
>> If I create views like "edit", then all the fields in the Role table, go
>> into a Form and are editable.
>>
>> So, now, in the edit.ctp, I am comparing the name to see if I want to
>> make it editable.
>>
>> if (in_array($this->request->**data['name'], array('owner',
>> 'admin','member'))) {
>> echo $this->Form->label('Role.name'**, 'Role:
>> '.$this->request->data['name']**);
>> } else {
>> echo $this->Form->input('Role.name'**);
>> }
>>
>> I have several things like this that are either displayed (not editable)
>> or editable depending on the role or permissions of the user. I don't
>> want to create different controller functions and different views for
>> each variation. But, I am also not sure that passing a bunch of
>> information to views and have them make the decision is right either.
>>
>> Anyone have any suggestions?
>>
>> Thanks,
>> bill
>>
>> ------------------------------
>> View this message in context: How to avoid extra php code in
>> views<http://cakephp.1045679.n5.nabble.com/How-to-avoid-extra-php-code-in-views-tp5689970.html>
>> Sent from the CakePHP mailing list
>> archive<http://cakephp.1045679.n5.nabble.com/>at Nabble.com.
>>
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org
> Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
>
>
> To unsubscribe from this group, send email to
> [hidden email] <http://user/SendEmail.jtp?type=node&node=5691020&i=0> For
> more options, visit this group at http://groups.google.com/group/cake-php
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://cakephp.1045679.n5.nabble.com/How-to-avoid-extra-php-code-in-views-tp5689970p5691020.html
> To start a new topic under CakePHP, email [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5691602&i=0>
> To unsubscribe from CakePHP, click here.
> NAML<http://cakephp.1045679.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
> ------------------------------
> View this message in context: Re: How to avoid extra php code in
> views<http://cakephp.1045679.n5.nabble.com/How-to-avoid-extra-php-code-in-views-tp5689970p5691602.html>
>
> Sent from the CakePHP mailing list
> archive<http://cakephp.1045679.n5.nabble.com/>at Nabble.com.
>
> --
> Our newest site for the community: CakePHP Video Tutorials
> http://tv.cakephp.org
> Check out the new CakePHP Questions site http://ask.cakephp.org and help
> others with their CakePHP related questions.
>
>
> To unsubscribe from this group, send email to
> cake-php+unsubscr...@googlegroups.com For more options, visit this group
> at http://groups.google.com/group/cake-php
>
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscr...@googlegroups.com For more options, visit this group at
http://groups.google.com/group/cake-php
