<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<pre wrap="">On Aug 28, 2007, at 4:04 AM, Karoly Negyesi wrote:
> Changing user_access could lead to very obscure and hard to debug
<span class="moz-txt-citetags">> </span>priviledge escalation holes: some code may make presumptions about
<span class="moz-txt-citetags">> </span>if a page is allowed by menu then certain permissions are set which
<span class="moz-txt-citetags">> </span>might not be true if you fiddle with roles on the fly. Saying that
<span class="moz-txt-citetags">> </span>this does not happen currently won't change the fact that it could.
</pre>
<pre wrap=""><!---->Let me again make it crystal clear: The user_access() patch I submitted here <a class="moz-txt-link-freetext" href="http://drupal.org/node/170524">http://drupal.org/node/170524</a> does NOT change user roles or alter current user_access functionality or permissions in any way. It simply resets the permissions calculated by user_access. It clears the cache. AND, it's optional! You have to send the command: user_access('', NULL, TRUE) in order for it to execute, otherwise, user_access is not affected at all. So, if you don't need it, you don't use it.
> Just overdefine the menu item that you want to change and define
<span class="moz-txt-citetags">> </span>your access mechanism. Because node/add is defined as cached you
<span class="moz-txt-citetags">> </span>can put your menu definiton in !$may_cache with the same path -- it
<span class="moz-txt-citetags">> </span><!---->will overwrite the original definition. In Drupal 6, you want to do a
The OG User Roles (OGR) module basically performs most of the functionality most users need it to do now, and with no patches to the core module, and no "overdefinitions" in hook_menu. It utilizes $user->roles because that's what $user->roles was designed to do: Tell you what permissions a user has. This whole current issue arose because I discovered user_access() was caching permissions and thus causing a problem with OGR and the upload.module. And, there was no way to clear this cache like there is practically everywhere else in Drupal. I further realized that this same issue had caused compatibility problems with the BuddyList, OG Forum and Relativity modules which, as you suggested, I wrote around to resolve.
However, at some point, it seems ridiculous to keep trying to write customized code for every module where I have this problem when the simple solution is to reset the cache, a rather harmless option that should be available everywhere that Drupal creates a cache (including user_access()).
I know you don't want to support role changes on the fly, but killing Peter to spite Paul doesn't seem like a logical way to do it.
-ron
</pre>
<pre class="moz-signature" cols="72">--
Ron Parker
Software Creations <a class="moz-txt-link-freetext" href="http://www.scbbs.com">http://www.scbbs.com</a>
Self-Administration Web Site <a class="moz-txt-link-freetext" href="http://saw.scbbs.com">http://saw.scbbs.com</a>
SDSS Subscription Mgmt Service <a class="moz-txt-link-freetext" href="http://sdss.scbbs.com">http://sdss.scbbs.com</a>
Central Ave Dance Ensemble <a class="moz-txt-link-freetext" href="http://www.centralavedance.com">http://www.centralavedance.com</a>
R & B Salsa <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</body>
</html>