Stand With Ukraine. Stop Putin. Stop War.

When MODX Security bites you in the butt

The manager on my site handles a couple of site. First of all it is, obviously, where I write these articles. Then there was a Dutch translation in the works in a seperate context, as well as another one for the HandyMan website. Every now and then there's somebody who helps me out with these. There's someone translating for me, there's some people who help out on the HandyMan website and then a few more that need access to my main site.

At first I just gave them all full out access, but to provide a little more customization and security for myself I decided to set up a couple of user groups with just the permissions people will need. One of these involved the elements such as chunks and templates. Users working on the HandyMan site don't need access to my main site template or the other way around.

So I set up some access levels. I decided to do it quickly, and set up one "MH Admin" group which has access to the main site context and its elements. That would mean any other user groups (minus the main Administrator one which already had access to everything) only has access to the others. This is, in case you don't know yet, because the security system locks out user groups that do not have the permission in case you set it explicitely. So first everyone's allowed - but when you give one user group explicitely access to it, it will block all the rest. No problem! That's exactly what we want.

Fast forward a month.

It is now June, and a week ago I updated MODX to 2.1.1-pl, and set up a new context related to the development of a new website - this one! Fresh content, fresh layout etc. All good. But suddenly, a week after setting that up, while browsing the site it seems some pages have eaten their template! Nothing shows up, but just the content.

Theory 1: corrupted cache

Okay... odd. Now let's think. What could've caused this? Let's just refresh the cache to make sure we're not just dealing with an incidental corrupt cache or anything. Cache cleared, back to the website, all good. Alright then - back to work!

Theory 2: context settings

Now about an hour later I end up watching my website again, and guess what? Same problem all over again! I didn't settle with clearing the cache this time, but instead kept browsing around in order to see if I can replicate it on the website. At one point I just totally couldn't find it and decided to make a note about it on my homepage just in case it would happen again. So I make the modifications and press the "View" button to check how it looks. But wait! The "View" button doesn't work, but attempts to open a javascript code as webpage. So I went to check the site_url setting in the context, to find it wasn't there.

I never set them on the "web" context for the simple reason that it wasn't needed. The web context runs just like it would be the only one. But, or so I guessed, the fact that I recently added a development context for my new site without settings either (did not want it public yet) might have been the problem. Let's set some settings such as site_url and try again. Yay, it's back up!

... or is it?

What actually was the problem

The problem was that it would not be parsing my templates, chunks and so on. My elements. The same ones that I protected a month earlier in the back-end to make sure only the people I want to be able of accessing could actually see them. After receiving another text message asking if I made my website "Mobile friendly" (yes, that's you Taco!!) it seemed the problem was still there. Aaargh!

Figured it out yet? If you didn't, don't worry - at this stage I didn't either. If you did, where were you when I needed you?! :P

If you remember (or scroll back up) you'll see how I explicitely set my MH Admin user group to be able of accessing these specific categories. What that meant is that any other user groups would not. But that's what we want right? Actually - there's one flaw in there, which may stem from still being used to the Evolution security systems in which you had the division between web and manager users. In Revolution, you do not but instead they can be used for both or just one of them. The user group that caused this was the (anonymous) one - a user group representing people that are not logged in. Site visitors. People who will want to see my templates and other elements.

So because I only explicitely allowed my MH Admin user group to access these elements, they were automatically hidden from other user groups.

Including valuable visitors.

The fix was easy - just give the (anonymous) user group access to these elements as well, using the access control of "Load, list and view". Flush permissions, clear cache and back to the site. Test in three browsers and ask three other people from all over the country to do the same. I am now confident to say the problem has been fixed.

So that's all?

Now there's one more thing that I didn't explain yet, which has seriously made this fault hard to track down. I know this system quite well, and this had me puzzled for days.

One word: Caching.

My site is cached as much as possible, which includes complete resource caching. So whenever a page is requested (by anyone) it is cached. This anyone is often me - whenever I change something I check it out, and click around a bit to check out comments etc. All the resources I visited were added to the cache, and these often were the ones that were most visited as well. So whenever I visit a resource while being logged in, it gets cached with my permissions.

But, and this was the problem, when a resource was not cached it would use the anonymous user group permission and MODX would refuse to display the templates and other elements. As a result it would just dump the content with no errors (it's intended behavior, not something failing) or any clues.


So that's what kept me busy over the past period. And I hope this article can prevent you from having to do the same. :)