[development] Changing Roles (was Deleting Cached Permissions)

[Ken Rickard]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070828/a9cba34d/attachment.htm