Re: [development] Changing Roles (was Deleting Cached Permissions)
Let me say it again: OG User Roles does not CHANGE roles. It adds roles based upon the group a user and node is in. For those who can't think of any scenario where a temporary role addition is a good idea, what about this: User 1 belongs to Group A and Group B. In Group A, User 1 is a contributor and can add content. In Group B, User 1 is a member, and can only read content. The way Drupal works now, if you give User 1 "create content" role in Group A, the user will also have the same role and capability in Group B. For that matter, the user will have the "create content" role across the entire site. What OG User Roles (OGR) does is give the user the "create content" role in Group A, but NOT Group B. So, I wouldn't give User 1 a sitewide "create content" role, but a group "create content" role, and only in Group A. OGR doesn't alter sitewide roles, but adds temporary roles based upon group context. In the bigger Drupal scheme, this apparently has no value. But, with respect to Organic Groups and totally autonomous communities within communities, this is the only secure way of achieving that. I can have 100's of groups and subgroups, one or two node types, and use only 4 roles: founder, admin, contributor, member; and, not one member of any group will be able to create or see content in any other group that he/she shouldn't. This is NOT possible now, not without having 100's of roles and 100's of node types. If the Drupal development team doesn't think this is a good idea, so be it. Deleting cached permissions, however, is a separate issue. I still don't see why being able to delete cached permissions is NOT a good idea. -ron Date: Tue, 28 Aug 2007 07:04:57 +0200 (CEST) From: "Karoly Negyesi" <karoly@negyesi.net> Subject: Re: [development] Deleting Cached Permissions To: development@drupal.org Message-ID: <E1IPtG5-0006zX-9v@garm.runbox.com> Content-Type: text/plain; charset="iso-8859-1" I can not imagine any scenario where a temporary role change is a good idea .If it's permanent you can reload Drupal. What are your goals? "use LDAP groups" is a task not a goal. "I want to herd a tribe of gutsy gibbons" now, that's a goal. -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com
Finally, we have a goal: "I want to change access control to a certain page based on various input (like GET) variables". Just overdefine the menu item that you want to change and define your access mechanism. Because node/add is defined as cached you can put your menu definiton in !$may_cache with the same path -- it will overwrite the original definition. In Drupal 6, you want to do a hook_menu_alter and use your own access callback. This does not need fiddling with core. Changing user_access could lead to very obscure and hard to debug priviledge escalation holes: some code may make presumptions about if a page is allowed by menu then certain permissions are set which might not be true if you fiddle with roles on the fly. Saying that this does not happen currently won't change the fact that it could. Regards, NK
Isn't hook_node_access() the proper way to handle this requirement? I just wrote a node access module that assigns nodes to subdomains (affliated sites using site.example.com, site1.example.com, and so on). Some users have the permission 'create X content', other have the permission 'create subdomain content', which allows them to create content type X only if they are creating or editing a node that belongs to a specific subdomain. I would imagine the OGR would use a similar approach. Some users would have a universal 'create' privilege. Others would have 'create only in my groups' privilege. I may be very wrong, but it seems like changing roles temporarily is a hackish way to do something that is more fully supported with the Node Access API. - Ken On 8/28/07, Karoly Negyesi <karoly@negyesi.net> wrote:
Finally, we have a goal: "I want to change access control to a certain page based on various input (like GET) variables".
Just overdefine the menu item that you want to change and define your access mechanism. Because node/add is defined as cached you can put your menu definiton in !$may_cache with the same path -- it will overwrite the original definition. In Drupal 6, you want to do a hook_menu_alter and use your own access callback. This does not need fiddling with core.
Changing user_access could lead to very obscure and hard to debug priviledge escalation holes: some code may make presumptions about if a page is allowed by menu then certain permissions are set which might not be true if you fiddle with roles on the fly. Saying that this does not happen currently won't change the fact that it could.
Regards,
NK
----- Start Original Message ----- Sent: Tue, 28 Aug 2007 08:57:19 -0400 From: "Ken Rickard" <agentrickard@gmail.com> To: development@drupal.org Subject: Re: [development] Changing Roles (was Deleting Cached Permissions)
Isn't hook_node_access() the proper way to handle this requirement?
Create is a bastard here because it's not overrideable. I had a patch long long ago which tried to create a 'create' op in nodeapi...
Is that a bug in node_content_access() ? -Peter On 8/28/07, Karoly Negyesi <karoly@negyesi.net> wrote:
----- Start Original Message ----- Sent: Tue, 28 Aug 2007 08:57:19 -0400 From: "Ken Rickard" <agentrickard@gmail.com> To: development@drupal.org Subject: Re: [development] Changing Roles (was Deleting Cached Permissions)
Isn't hook_node_access() the proper way to handle this requirement?
Create is a bastard here because it's not overrideable. I had a patch long long ago which tried to create a 'create' op in nodeapi...
It's a design hole. You cant' have an entry in node_access table to control behavior of a node that doesn't exist yet. If we took a different approach to node access using a relationship API. Modules would all need to implement permissions along the lines "Add Book Pages" differently than "Create Books", and have that concept scale similarly to concepts like organic books. Dave On Aug 28, 2007, at 7:10 AM, Peter Wolanin wrote:
Is that a bug in node_content_access() ?
-Peter
On 8/28/07, Karoly Negyesi <karoly@negyesi.net> wrote:
----- Start Original Message ----- Sent: Tue, 28 Aug 2007 08:57:19 -0400 From: "Ken Rickard" <agentrickard@gmail.com> To: development@drupal.org Subject: Re: [development] Changing Roles (was Deleting Cached Permissions)
Isn't hook_node_access() the proper way to handle this requirement?
Create is a bastard here because it's not overrideable. I had a patch long long ago which tried to create a 'create' op in nodeapi...
On Aug 28, 2007, at 4:04 AM, Karoly Negyesi wrote:
Just overdefine the menu item that you want to change and define your access mechanism. Because node/add is defined as cached you can put your menu definiton in !$may_cache with the same path -- it will overwrite the original definition. In Drupal 6, you want to do a
Karoly, thanks for bringing up some options for a solution. This might work with the new menu system, provided we have a way to override other modules menus access control. Is that what you're suggesting? But what Ron is trying to do is override permissions for other modules, (book, page,etc.). That means that Ron needs a way to overdefine all of the menu items for node/*/add. Will that work, or does the uniquely defined menu item supercede the other. Would overriding these menu items be thought of as a "supported way" of writing a module? If you're suggesting duplicating all of the modules menu code in the organic groups module, I don't see how mucking with the other peoples menu structures on other modules is fundamentally cleaner than elevating a role. There's a lot more opportunity for funky behavior. Then there's the problem that menu items are also cached. So we run into similar prolbems there yes?
Changing user_access could lead to very obscure and hard to debug priviledge escalation holes: some code may make presumptions about if a page is allowed by menu then certain permissions are set which might not be true if you fiddle with roles on the fly. Saying that this does not happen currently won't change the fact that it could.
Aren't all of these issues still there if you fiddle with menu access control on the fly? If not, why is it different? Ron isn't asking for a way to escalate privileges that isn't supported. Ron is asking for control about whether drupal caches those permissions. As I've said, this has implications for any module that wants to alter a users role, whether it does so temporarily or on login. I've fought similar bugs in my cas module, but I can see problems here with LDAP Groups and other modules that want to alter a users role programmatically. I think it's odd to say we don't want to support a mechanism because we're worried it will be called to often. It's only the frequency of the call that seems to be in debate here. (I don't want users to be able to change roles on every page load).
Regards,
NK
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Metzler schrieb:
On Aug 28, 2007, at 4:04 AM, Karoly Negyesi wrote:
Just overdefine the menu item that you want to change and define your access mechanism. Because node/add is defined as cached you can put your menu definiton in !$may_cache with the same path -- it will overwrite the original definition. In Drupal 6, you want to do a
Karoly, thanks for bringing up some options for a solution. This might work with the new menu system, provided we have a way to override other modules menus access control.
This has worked since Drupal 4.x. Overriding the menu path is a way to replace entire pages from Drupal core.
Is that what you're suggesting? But what Ron is trying to do is override permissions for other modules, (book, page,etc.). That means that Ron needs a way to overdefine all of the menu items for node/*/add. Will that work, or does the uniquely defined menu item supercede the other.
IMO he only needs to copy the logic in node.module's hook_menu and make sure his module has a higher weight.
Would overriding these menu items be thought of as a "supported way" of writing a module?
It's a bit nasty, but I have done so several times. Mostly for client projects where one standard page wasn't acceptable to the client or wasn't modifiable in another way. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG1DFUfg6TFvELooQRAnUXAJ9ySp5/fQjCEh30oyl0qfLUI3o68ACgvhzi ma0e159MSbvfBqfxbt4/+A8= =u5RP -----END PGP SIGNATURE-----
On Aug 28, 2007, at 10:21 AM, David Metzler wrote:
I think it's odd to say we don't want to support a mechanism because we're worried it will be called to often. It's only the frequency of the call that seems to be in debate here. (I don't want users to be able to change roles on every page load).
To that one could add, If a feature is considered harmful, it should be removed. Preserving bugs doesn't solve anything.
participants (7)
-
Darren Oh -
David Metzler -
Gerhard Killesreiter -
Karoly Negyesi -
Ken Rickard -
Peter Wolanin -
Ron Parker