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] </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
> ml-node+s1045679n125572...@n5.nabble.com
> To unsubscribe from CakePHP, click here
> <http://cakephp.1045679.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1255722&code=YmlsbC5zdG9sdHpAYm9vc3RlcndlYnNvbHV0aW9ucy5jb218MTI1NTcyMnwtNTU0NTk2MTUy>.
> 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:
http://cakephp.1045679.n5.nabble.com/How-to-avoid-extra-php-code-in-views-tp5689970p5691602.html
Sent from the CakePHP mailing list archive 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
