Need help with permission mystery in CMP

I’m working on an updated version of RefreshCache. I have a processor that calls Mark Hamstra’s Guzzle7 client->head($uri); to cache all published resources with a visit to each page.

It works most of the time, but fails for a particular condition. I’ve tried about 100 things to fix it with no luck.

It refreshes all unprotected resources. It also refreshes resources that are in a Resource Group that is not connected to any User Group with a Resource Group Access ACL entry.

It fails, when a Resource is in a truly protected Resource Group, even when I (the admin user) have access to that Resource Group. For example: the Resource Group of the Resource is connected to the Administrator Group. At the point where the call is made, I’ve verified that I am the admin user, that I am a member of the Administrator User Group, and that I’m logged in to either the web or mgr contexts (or both). There are Context Access ACL entries giving me access to both contexts. There are Resource Group Access ACL entries connecting the Administrator User Group to the Resource Group (AllDocs) in both contexts. The current context is reported as mgr.

If I get the resource just before the call and test with $doc->checkPolicy('view_document'), it says I have permission for all the unprotected docs, but not this one.

Here’s where it gets really weird. If I make myself a sudo user, it says I have permission for the failed document, but it still doesn’t refresh the cache for that document.

This failure happens with any Resource that is in a Resource Group that’s connected to a User Group by a Resource Group Access ACL entry, even though I’m a member of all User Groups and have the highest authority level (and can verify my membership at the point where the call is made).

The $uri is always correct, and I can view any resource by pasting in the address used in the call into the browser’s address window.

I’ve tried reloading the context on every call. There are no error messages in the MODX error Log. The call does not throw any exceptions, and the Network tab shows a 200, and a "success’ message in the response.

Everything is the same for MODX 2 and MODX 3, with PHP 8.

I have the feeling I’m overlooking something simple, so I’m hoping sharper brains than mine can make a suggestion that will help me solve this. The extra is unusable at this point, since a user might have a protected Resource Group that contains all resources, in which case no Resources would be cached.

Do you add any credentials to the Guzzle client?

When you make a request from your browser to your MODX server, you are authenticated by the browser cookie.
But a request with Guzzle from your MODX server to your MODX server won’t have this cookie (to identify you as the administrator).

That sounds like a good theory. Thanks!

I’ll have to figure out how to convince MODX via Guzzle that I’m logged in as the admin, without compromising security.