After upgrade to 2.2.8 problem "access denied" on save

I tried one of the above fixes and got scared as my resource tree would not display after I'd done it. Quickly reverted back. We're all in the same boat here. Main issue has been the devs have had trouble reproducing the bug, despite it being (in my humble opinion) pretty widespread.

I do have high hopes for a fix in 2.3 though

Only one instance of this problem has been identified and resolved by myself, and the particular user in question was having it caused by visiting the front-end of his site in the same browser session as the manager. Disabling sessions in his front-end Contexts as well as just not visiting the front-end of the site in the same browser session avoided the problem.

So what I could really use is confirmation or denial that this is the only trigger causing this behavior. Or, if you can isolate the specific trigger on your site be trying to disable various plugins and/or snippets, that would also be very helpful.

Quote from: opengeek at Oct 31, 2013, 07:05 AM

Only one instance of this problem has been identified and resolved by myself, and the particular user in question was having it caused by visiting the front-end of his site in the same browser session as the manager. Disabling sessions in his front-end Contexts as well as just not visiting the front-end of the site in the same browser session avoided the problem.

So what I could really use is confirmation or denial that this is the only trigger causing this behavior. Or, if you can isolate the specific trigger on your site be trying to disable various plugins and/or snippets, that would also be very helpful.

I can confirm there was only one window open on the website when it happened, ie. the front end wasn’t loaded in another browser tab/window. Logging out and back in again resets something which makes it work, doesn’t appear to be any discernable pattern to whether it will work or not.

I’ve implemented the temporary fix suggested on page 6 above for now, difficult to test with disabling/enabling packages as it is so sporadic. If it happens again I will start disabling things to see if that resets the problem without having to log out.

I've been having another play with this. It is just so hard to make happen. It always just seems almost random.

I would generally have a manager window and a page on the site open in a different tab most of the time, I still don;t know how to reproduce it though.

Does it happen still on 2.2.10?

Yep - still there in 2.2.10

2.2.10 Have it. I developed a site and testing as user. Got "Access Denied". Log out, clear browser cache, and log in. Working.

Then I logged out and log in as administrator (same browser). Got error on save. Log out, clear browser cache, log in. Working.

@Valokammi is still a developement site? otherwise could you give access to modx staff so that they can check it?

Quote from: tillilab at Nov 13, 2013, 02:19 AM

@Valokammi is still a developement site? otherwise could you give access to modx staff so that they can check it?

Well I wasn`t very spesific. Sorry about that. Site is a production site.

My experience (under chrome and firefox, on Mac or Ubuntu, with rev. 2.2.8-pl is that the "access denied" issue is not connected whether with having several tabs opened in the same browser, nor with having several users logged in at the same time.

I open chrome with one tab, log me into the manager in this very tab, I am alone working on the manager. I try to save any resource. Boom! "access denied". Log out, log in again - saving is working. No flushing permissions required. I try to repeat this by closing the browser, emptying the cache, to no avail: saving does work.

I am looking for patterns but can't seem to find any.

Did a bit of searching around my localhost and the bazillion files in there, and looked specifically for places that might result in setting the auth session to zero ($_SESSION['modx.CTX.user.token']) instead of an empty string, as the core would.

I don't have a solution but am documenting what I came across - perhaps it raises any questions or sparks any bright moments in others that helps narrow it down where to look..

Discuss connector. The conditions for that seem to be Revo 2.2.1+, when the user is not logged into the active context (if no context is specified it defaults to mgr) and when a specific action is specified. Based on my experience with Discuss, this would be quite unlikely to occur regularly as there's only one action (searching for a user to PM) that I know which is actually used.

SimpleCart (note: an old version) sets the $_SERVER['HTTP_MODAUTH'] variable to $modx->site_id, which probably resolves to null because site_id no longer exists, and could set the value to 0. This also sets $_SESSION['modx.CTX.user.token'] to $modx->site_id. Again though, old version of SimpleCart (1.1-ish?) so might not be accurate anymore.

GatewayManager uses the same code as SimpleCart in its connector, possibly same issue there.

Dropbox media source DropSource (never released) uses similar logic as Discuss in its connector, but as that was never properly released, I doubt that could be the source of so many people having issues.

As Gallery was highlighted by Jason I checked that one too, and that follows the same logic as Discuss, limited only to when the web/phpthumb action is called.

ModxPros component also uses the Gallery/Discuss logic limited to 2 actions.

Updated
The ExtJS modal that extends a session (so the one that pops up saying you have to login again) overwrites the javascript MODx.siteId variable (and ExtJS modAuth/HTTP_MODAUTH params) based on a returned token from the javascript. If that token would be zero, that could cause the issue across the manager as most places that specifically need the auth code access MODx.siteId.

The MODX Browser controller (manager/controllers/default/browser/index.class.php) also sets MODx.siteId from the getUserToken method for the current context ($this->modx->context), in the loadCustomCssJs function. In the process function it checks for a ctx param to set $this->ctx, shouldn't that be looking at the wctx (working context), like the modManagerController getWorkingContext method?
Usage of the browser seems to be restricted to TinyMCE, which calls it in an iframe with url manager/index.php?a=3&ctx=site&wctx=site&source=1&v=228pl (when editing in a context called "site"). The returned html shows the right auth code in MODx.siteId in the header wether I'm logged in to that specific context (according to the Login snippet) or not. Seems to work okay.. [ed. note: markh last edited this post 12 years, 8 months ago.]