Site Unavailable error after editing permissions/users/groups

Hello Forum,

I need your help again, any idea or approach with this error:

I have a multi-context / multi-language site working smoothly until I was adding manager-users today, with groups of course, and policies. the goal is to add different users to manage individual languages.

but I did not even define context-access or any other access rules to the new groups yet, when all contexts but the web-context, loaded via their subdomains, stopped working and displaying the Site Unavailable message. So only web context is available.

I reversed every step until everything little piece of permisson related setting was as before, but the error still persists.

the messages are shown when not logged in, as well as to my Administrator Superuser.

- I did nothing else when the error started, no update, upgrade, install, plugin...
- the context's site_status value is still ´yes´ on every context
- apache's error log is empty (at least no error in this timespan)
- in the modx log there is nothing but errors that correspond exactly to http://bugs.modx.com/issues/3218, so this also is no hint nor help

I would urgently need and appreciate any idea where I could find a trace, hint, track of what causes the error.

thank you!
~d

You've probably tried some of this already, but if you can access the Manager, flush permissions and sessions, then -- while logged out -- delete all the files in the core/cache directory and clear your browser cache and cookies before checking the site.

If that doesn't do it. Go into PhpMyAdmin and see if you have any crashed tables.

Hello and thank you BobRay once more for the quick answer!


Ok, I think I have to spend extra hours with the revo permission system.

I flushed permissions and browsercache almost after every little step and tables are ok (a system setting cache_permissions would be fine). didn't clear cache-dir though. but:

I removed context-access rules for my Administrator-user and the contexts are released again. So it seems to be my fault but I don't know whats wrong:

I had Context Access rules for the individual contexts (minimum role: Member, Load Only and Administrator policy) for anonymous and Administrator. Removing them alltogether did the trick.

But aint it said that every User Group that needs to have access to a Context needs to have a corresponding User Group Access to Context set with minimum role and Access Policy?


In my opionion the error message "unavailable" instead of "access denied" is misleading but I have two questions:

1. is there a way to debug permissions?
2. are there how-tos or examples for permission configurations especially for multi-context sites?

thank you!

1. Sadly, not that I know of.
2. Sort of: http://bobsguides.com/revo-security-tutorials.html. There are other tutorials around as well.

There is no specific tutorial for multiple contexts because all other front-end contexts are exactly like the 'web' context. Everything you know about the 'web' context applies to all other contexts except the 'mgr' context.

It sounds like you may have the principles somewhat backwards, though. In the front end, users only need ACL entries for resources or contexts that are protected.

Any new context is unprotected until you protect it by creating a Context Access ACL entry for it. It's then protected from any user that doesn't qualify for that ACL entry.

The same thing is true of resource groups. The resources in them are unprotected until you create a Resource Group Access ACL entry connecting them to a user group. Once you do that, the resources are protected from visitors who are not in the group and users in the group that don't qualify.

One key guideline that might have helped you: Never put a context's site_start, error_page, or unauthorized_page in a resource group. You almost never want to protect ("hide") them, so there's no point and it just causes trouble.

Similarly, never put a resource in a resource group unless you want to hide it from somebody.

If you want to hide resources in a resource group in the Manager only, don't create a Resource Group Access ACL entry for for the resource group with a context of 'web'.

Conversely, if you want to hide resources in a resource group in the front end only, don't create a Resource Group Access ACL entry for the resource group with a context of 'mgr'.