Re: [development] Deleting Cached Permissions
Then, could someone help me with some process or procedure by which I could prevent user_access() from caching $perm or override the results of this caching? Even if I turn Drupal caching off, this function's caching of $perm still occurs, causing my module problems where it shouldn't have them. Thanks! -ron Quoting Ron Parker <sysop@scbbs.com>:
That is: The user_access() function sets a static variable $perm = array(). Permissions are cached in this variable. Can I create a function in my module that can update the $perm variable that is set in the user_access() function of the node.module?
A variable declared within a function is private to the function unless the function declares it as global. Earnie -- 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
Quoting Ron Parker <sysop@scbbs.com>:
Then, could someone help me with some process or procedure by which I could prevent user_access() from caching $perm or override the results of this caching? Even if I turn Drupal caching off, this function's caching of $perm still occurs, causing my module problems where it shouldn't have them.
Have you considered that maybe cache_filter is the issue rather than user_accesses $perm? I don't understand why the cached permission of an authenticated user would interfere unless the permissions are changing for some reason. Earnie
The permissions (user roles) are being altered temporarily. The reasons are documented in the issue Ron has referenced. Ron, it sounds like Moshe was suggesting that adding the reset parameter to user_access *might* be looked on favorably as a submitted patch to core. having control over a caching behavior seems like a reasonable request with little downside. Given that its a really small patch, you might try filing it and see if it gets some attention. I know you've been trying to come up with a resolution to this issue for a long time. I applaud your patience :). Good luck on this. Dave On Aug 24, 2007, at 5:36 AM, Earnie Boyd wrote:
Quoting Ron Parker <sysop@scbbs.com>:
Then, could someone help me with some process or procedure by which I could prevent user_access() from caching $perm or override the results of this caching? Even if I turn Drupal caching off, this function's caching of $perm still occurs, causing my module problems where it shouldn't have them.
Have you considered that maybe cache_filter is the issue rather than user_accesses $perm? I don't understand why the cached permission of an authenticated user would interfere unless the permissions are changing for some reason.
Earnie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Metzler schrieb:
The permissions (user roles) are being altered temporarily. The reasons are documented in the issue Ron has referenced.
I've said it once and I say it again since apparently nobody noticed: Temporarily changing user roles (per page request) is (currently) unsupported by Drupal. I'd even argue that it shouldn't be supported and that what Ron is doing should be achieved in another way. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGz9tkfg6TFvELooQRAu7yAKCHUg0KbF+Aj0l5VsE4Nmn6cTUTmgCgo39m G+VDt5ihnhiN7eEGKXg9lX8= =llJu -----END PGP SIGNATURE-----
Although I'm not sure I share your view, I can certainly respect your opinion here. At one point in time. Ron is bumping up against hard limits on node_access which currently does not allow for value based security to be attached to a node add event. On the issue in question, several alternatives were debated, but none got any traction. All have suggested node_access revamp. Which is a much bigger issue. That being said, the static caching of mechanism of user_cache will affect any module that tries to elevate roles behind the scenes whether temporary or permanently. These are potential issues for other modules such as LDAP groups or others that seek to set role membership based on a login event without user intervention. I think that having control over a cache mechanism is not an unreasonable request. Or stated in another way, I'm not sure that giving developers control over a cache mechanism is a security concern. So yes, I noticed, but this seemed like the most secure of the options that I've seen IMHO. Time will tell wether core commit team agrees. Dave On Aug 25, 2007, at 1:52 AM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Metzler schrieb:
The permissions (user roles) are being altered temporarily. The reasons are documented in the issue Ron has referenced.
I've said it once and I say it again since apparently nobody noticed:
Temporarily changing user roles (per page request) is (currently) unsupported by Drupal.
I'd even argue that it shouldn't be supported and that what Ron is doing should be achieved in another way.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGz9tkfg6TFvELooQRAu7yAKCHUg0KbF+Aj0l5VsE4Nmn6cTUTmgCgo39m G+VDt5ihnhiN7eEGKXg9lX8= =llJu -----END PGP SIGNATURE-----
I just noticed that chx marked this issue as won't fix. As one o the contrib users who continually bumps up against this permissions caching issue, can we hear about alternatives? This isn't just about per page security, but also a barrier to any dynamic role based system. Including LDAP Groups and others. If we really want barriers against programatic control of roles, then how should Ron implement this? Can anyone suggest a way to deal with this problem? Can we agree that implementing value based security for "Add" events is a good thing and get on to suggesting a solution to the problem? Dave On Aug 25, 2007, at 1:52 AM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Metzler schrieb:
The permissions (user roles) are being altered temporarily. The reasons are documented in the issue Ron has referenced.
I've said it once and I say it again since apparently nobody noticed:
Temporarily changing user roles (per page request) is (currently) unsupported by Drupal.
I'd even argue that it shouldn't be supported and that what Ron is doing should be achieved in another way.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGz9tkfg6TFvELooQRAu7yAKCHUg0KbF+Aj0l5VsE4Nmn6cTUTmgCgo39m G+VDt5ihnhiN7eEGKXg9lX8= =llJu -----END PGP SIGNATURE-----
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.
I want users to not get "Access Denied" messages the first time they hit a page when LDAP says, you now have permissions to this. Oh yeah, they can just hit refresh, (and jump up turn around and clap their hands) in order to avoid the error message. I just don't seeing code that behaves this way. I like temporary role changes. I think they are better than doing things like "become user 1" to perform this operation, because it preserves the audit trail. It also opens the door to letting a user temporarily do things without giving them user 1 level context. So I guess we'll disagree on that one. Either way, I still think we're talking about his og code and not the user_access code that's being talked about. Why is cache control such a bad thing? Dave On Aug 27, 2007, at 10:04 PM, Karoly Negyesi wrote:
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.
participants (5)
-
David Metzler -
Earnie Boyd -
Gerhard Killesreiter -
Karoly Negyesi -
Ron Parker