Connectors/index.php error NOT mod security

Hi guys, I have a vps with all the right requirements. When I try to save a template on my modx install, or a chunk with any code in it I’m getting the following console errors:

[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (index.php, line 0) (connectors/index.php)
[Error] TypeError: this.mask.addClass is not a function. (In 'this.mask.addClass("fade-in")', 'this.mask.addClass' is undefined)
	onShow (modx.jsgrps-min.js:1:114390)
	afterShow (ext-all.js:21:375934)
	show (ext-all.js:21:375358)
	show (ext-all.js:21:387130)
	onAjaxException (modx.js:122)
	fire (ext-all.js:21:3705)
	fireEvent (ext-all.js:21:693)
	handleFailure (ext-all.js:21:51291)
	f (ext-base.js:21:18146)
	m (ext-base.js:21:18304)
	(anonymous function) (ext-base.js:21:8610)

[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (modx.jsgrps-min.js.map, line 0)

and if I navigate to connectors/index.php I see the following:
{"success":false,"message":"Access denied.","total":0,"data":[],"object":{"code":401}}

So I go to my code and see this:

/* check for anonymous access or for a context access policy - return error on failure */
if (defined('MODX_REQP') && MODX_REQP === false) {
} else if (!is_object($modx->context) || !$modx->context->checkPolicy('load')) {
    header("Content-Type: application/json; charset=UTF-8");
    header($_SERVER['SERVER_PROTOCOL'] . ' 401 Not Authorized');
    echo json_encode(array(
        'success' => false,
        'code' => 401,
    ));
    @session_write_close();
    die();
}

Gotcha. I’m going to see 401 anytime I try to access that file with a browser. Ok.

So I search forums. I find that EVERYONE has this issue who has mod security. Cool So I disable it. First on the domain then on the whole server.

STILL SAME ISSUE

I explain all of this to my tech support team at the datacenter. They insist this isn’t a server problem.

It’s a server problem.

I’m pretty darn sure that forbidden error is because of some security rule. I’ve checked file and directory permissions and cleared cache by hand and with the button. Flushed permissions. used a private browser. Changed my session variable in the settings to “/” and to “/modx/” which is my current subdirectory. I’ve installed by hand, different versions. I’ve used Softaculous. Same issues. I’ve checked the server logs for ANYTHING I can find.

I can duplicate a template with code in it. It works. (Dupe the included base template)

I can also create an empty template. Chunks or templates with html seem to trigger it. I saved a chunk of php successfully in a template.

There is no cloudflare running.

This is for me, to create a modx site for the new fantasy fiction book that I have written. FREE COPY to whoever helps me figure this out. I really need help.

1 Like

It only happens when saving a chunk or a template, and the rest of the manager works as expected? What about when you save a chunk or template that is completely empty?

empty is ok. I think there are issues with extras too but I havent tested yet. my sysadmin died and we had to move everything and this has been a consistent problem since we moved. one of the sites we did just suddenly started working. i am completely mystified

v 2.7.1

paths are ok and correct. nothing in my error log

I just successfully installed FormIt and some other Extras so I’m ok there

If it looks like a duck, swims like a duck, and quacks like a duck, then it is a duck mod security.

1 Like

I didnt trust my datacenter guys and so I installed my own modsecurity plugin in the WHM to turn it off. I turned it off myself and still nothing. I’m using ConfigServer ModSecurity Control - cmc v3.02 and turned it off for the domain, tested. nada. then the entire server. tested. nada. I agree with you but the only other security package I’m seeing is ConfigServer Security & Firewall - csf v12.11 which doesnt DO stuff like this. It’s not my culprit.

the rule for the domain is GET /

Action Description:

Access allowed (phase 1).

Justification:

Pattern match “annecmiles.com” at SERVER_NAME.

All I can say is that the behaviour you describe (only happens on certain requests with certain (html) content, 403 error returned) matches the symptoms of mod_security (or a similar WAF/firewall solution) perfectly. Perhaps there’s another package running, or a reboot/reload is needed for your changes to take affect.

The only other potential reason I can think of is MODX ACLs, but as you’ve indicated it’s a personal project (and you know your way around MODX well enough), I have serious doubts you would’ve configured element access in a way that would prevent you from, say, editing elements in specific categories. Easy to rule that out too, by enabling sudo mode on your user (if it wasn’t already).

Other potential causes that your description of events have already been ruled out:

  • File/directory permissions, as that would trigger on any request, not just requests with certain content.
  • Even file permissions on the specific processor file itself is not the root cause if you can still save the same type of element if it is empty.
  • Some sort of redirect causing access tokens (MODAUTH/session cookie) to get lost would also not happen on specific elements only.

Also, very sorry to hear about your loss.

thanks. we have had a rough year.

There are no ACLs. I was wondering about the session cookie. But I tried setting it and testing and it was the same. There is a place for me to disable all rules I’m going to try that.

I disabled all rules. same thing. The “forbidden” error is being caused by SOMETHING. Going to go back to the datacenter geeks. I don’t know what else to do. I’m paying a lot for this server and need this to just work.

ok so I have a Wordpress blog at the domain in question, to be replaced by my shiny new modx site. AND the problem was my Wordfence plugin which is awesome but apparently conflicts with MODX. If it is activated then we get this behavior. It didnt even occur to me that it might be an issue. Hope it helps someone else.

cheers

2 Likes

Glad you tracked it down finally.

I have these 403 errors too, when saving a template, a chunk or a snippet. My webhost changed some rules in mod_security and now it’s fixed for tempates and chunks. They have to do some more changes to get saving snippets working too. And probably for installing certain extra’s as well.
Is this a modx problem or a server security problem? Do I have to communicate with my webhoster for all my modx sites about these settings? This is really annoying. I’m not sure when these problems emerged, but I’m sure I didn’t have them before. Maybe after switching to https? Maybe after a Modx update?

1 Like

No, that’s not related to HTTPS or specific versions of MODX. It’s not new either - posts about this will go back a decade.

The problem comes from editing things like HTML and PHP code through a web interface. mod_security is a security feature that looks for suspicious code, and raw HTML and PHP being posted to a server is definitely suspicious.

It’s not impossible to run MODX on a server with mod_security, but it may require some tweaking of the mod_security rules to allow all administrative functions. Whitelisting the /manager/ and /connectors/ directories is also an option.

This also isn’t specific to mod_security - other types of server protections and firewalls can also cause similar results. I’m a big fan of CloudFlare for example, but their filters can also get flagged in a similar way as mod_security.

2 Likes

mod_security is a server-side security tool. it checks the contents of a page to look for bad stuff, but it does so in ways that can easily get triggered innocently.

i had a terrible time with mod_security because I have pages with a lot of text content, and text with repeating terms. none of the words were ‘casino’ but anyway these pages triggered and it takes a long time to remove one rule after another. in other words mod_security is sort of a blunt instrument. there are a lot of rules that it uses.

i did not opt to break up the pages but I believe that would have helped. its not content wide content, just each page.

i don’t know that Modx would be more or less likely than other CMS to trigger mod_security, but there are some threads here with useful suggestions to fix the problem with the help of your hoster.

I understand mod_security is an important tool, but it really gets in my way since a few months or so. Never in the 10+ years that I’ve been using ModX did I have such trouble with it.

I asked them to white-list the connector and manager directories, as you suggested, but they don’t bother, they keep adding exceptions as they rise. I’ve had contact with them on almost a daily basis for the last three weeks and it still isn’t fixed completely. Some things work, some don’t.

I am afraid that less experienced users will be scared away from ModX due to this. Even I consider finding a less demanding CMS. Or find another hosting company without this trouble, if that’s even possible. But that’s quite a hassle too. Any suggestions apart from modxCloud?

Shouldn’t the ModX team worry about this fact, taken in account that ModX can often easily be installed from an Installatron? Shouldn’t it work straight away then?
Could the ModX team perhaps take away (part of) this pain somehow? Maybe supply a list of exceptions or white-listings for my provider to apply to their mod_security? Or even better… make ModX work in a way that it doesn’t tickle security in such way?

I’m sorry for the amount of questions.

mod_security is a server-level security feature. No, the MODX application cannot influence that configuration. Requests caught by mod_security do not make it to the MODX application but are blocked before that.

The reason MODX is “demanding” is that you’ll often find yourself editing code or html from the manager. Snippets, templates, chunks. Content in some cases. mod_security filters tend to get triggered by structures contained in them. Other “less-demanding” systems might require you to edit templates and such over FTP.

It sure can be annoying. But other than removing the ability to edit elements from the manager, there’s very little that can be done about this from the application.

/connectors/ and /manager/ is the only whitelist needed. Keep prodding your host, or indeed switch elsewhere.

1 Like

My five cents. Yes, this is server feature! Among dozens of different MODX instances I met this problem only a few times on various hosts. And always this fixed via technical support, they are open and expand their white lists without any problems and quite quickly.

Thanks for answering again, I understand that ModX can’t influence the mod_security settings, but it might perhaps be possible to send the requests with unrecognizable content for mod_security, like maybe hashing it before sending and the receiving side would unhash it before processing. Like that mod_security could maybe remain unchanged and safer.

You can’t be sure that a hashed content doesn’t trigger another rule. If anything, I’d say a large seemingly random hash might actually look more suspicious.