If you want to think of a website that has a lot of the same
features that i am trying to implement with CakePHP, then think
about Google Groups. Lots of users, multiple groups, multiple
members, roles per group, etc, etc.
I agree, adding layers, adds complexity. To me, adding prefixes,
adds layers and complexity.
If you know the user's role and the CRUD permissions they have for
the specific controller, then it should be a simple matter to
display those fields that are editable and those that are not.
Sorry if I seem to keep driving back to a single point. All this
other discussion is Great. I love the theoretical, practical and
best practices discussions. They really help me to understand
CakePHP at a better level. We can start more threads on this as I am
sure others will benefit from this too.
But, I really want to dig deeper into where the control over what
and how things are displayed should reside.
Should the controller pass in the list of fields that can be edited
(using Form->input() ) -or- should you pass the information into
the edit.ctp and let it decide based on the role passed in?
Thanks again for everyone replies.
Bill
On 5/7/2012 1:41 PM, Justin Edwards [via CakePHP] wrote:
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
< [hidden email] >
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 .
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
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
[hidden
email] 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]
To unsubscribe from CakePHP, click here .
NAML
View this message in context: Re: How to
avoid extra php code in views
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
[hidden
email] 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
[hidden email]
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-tp5689970p5691671.html
To start a new topic under CakePHP, email
[email protected]
To unsubscribe from CakePHP, click
here .
NAML
--
View this message in context:
http://cakephp.1045679.n5.nabble.com/How-to-avoid-extra-php-code-in-views-tp5689970p5692602.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
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
