A while back, I published a blog article at Bob's Guides that gave me a 403 Permission Denied (Access Forbidden) error whenever I tried to view it. The solution was simple, though not at all easy to come up with. I thought I'd post the story of my diagnosis and treatment here in case someone else has a similar problem.
The Problem
The process of editing and saving the article was completely normal. It was the same process I used to save a ton of other blog articles. I couldn't see anything in the content of the article that might cause a problem. Whenever I tried to view the article, though, I got this:
403 Permission Denied
You do not have permission for this request
Diagnosis
In situations like this, I always delete all the files in the core/cache directory using the CacheClear Extra, and if that doesn't work, try another browser. Even after clearing the cache, I got the same error in any browser. The error came up very fast, which in retrospect should have been a clue.
My first thought was that it was an issue with mod_security, though I couldn't see anything in the content that would raise any red flags. I tried putting this in the php.ini file to turn off mod_security:
SecFilterEngine Off
When that had no effect, I wasn't sure if mod_security was really turned off (some hosts ignore the directive in php.ini). I deleted all the content in the article and replaced it with the word "test", but still got the 403 error.
This is approximately the point at which my hair began to be pulled out. I checked to see if I got the error with pages that were not blog posts. I did not. I tried adding a new blog post to see if it would also be inaccessible. It was not. I tried deleting the whole article and creating a new one from scratch to see if the error was still there. It was.
The Solution
At this point, I decided to file a ticket with the host, since it was a server error and they were in charge of the server. I got a response saying that they checked the server logs, but couldn't find anything relevant. In other words, I was on my own.
I have a friend who knows almost nothing about computers or programming. When I have an intractable problem, I explain it to her, and she pretends to follow what I'm saying. In at least two-thirds of the cases, a possible solution comes to me while I'm telling her why the problem can't be solved. As I was explaining it to her, I had a dim memory of creating some filters using rewrite rules in .htaccess to block malicious bots. At about that point, I realized that the pagetitle, alias, and URL of the article all contained the word "Admin".
I had spent time a while back looking at the output of the LogPageNotFound extra. It showed lots of bots, hammering away at the site looking for vulnerable files from various CMS platforms (I still see bots looking for the MODX "reflect" security hole, which went away years ago). It's wasteful of both time and resources to have the bots go through the entire MODX page-not-found loop for files that will never exist, so I created some rewrite rules in .htaccess that send a 403 response for them. The bots are often looking for a file or directory named "wp-admin" (the place every hacker goes to exploit WordPress vulnerabilities).
As I suspected, this line appeared in my .htaccess file:
RewriteCond %{REQUEST_URI} admin [NC,OR]
The word "Admin" in the URL of the article was triggering that rule and causing the 403 error. I changed that line in .htaccess to this, and the problem immediately went away:
RewriteCond %{REQUEST_URI} wp-admin [NC,OR]
Bob Ray is the author of the MODX: The Official Guide and dozens of MODX Extras including QuickEmail, NewsPublisher, SiteCheck, GoRevo, Personalize, EZfaq, MyComponent and many more. His website is Bob’s Guides. It not only includes a plethora of MODX tutorials but there are some really great bread recipes there, as well.