I'm not sure if there are any MODX Community members that haven't come across Bob Ray in some way or another. He's a legend on the forums and wrote the book on how to use MODX. Let's see what he has to say on managing security in MODX Revolution.
Hopefully this clears for confusion than it causes. Here we go!
12:15:46 - Running a bit late, haven't started yet but hey, probably not the first time any of us have missed a deadline!
12:18:35 - Bob Ray used to teach wind sailing!
12:18:50 - Security Permissions in MODX are a lot like learning how to wind sail, you feel like you are never going to get it until you do
12:20:56 - Bob is going to try and talk more about how MODX seems the security permission, rather than how you do
12:21:13 - Apparently Amsterdam's Red Light district was one of his analogies he planned on using? Now I'm curious...
12:21:57 - All security permissions are managed under Access Controls. (It's kind of hidden but you have to right click and update a user group to get to the settings)
12:22:30 - Context Access, Resource Group Access, Element Category Access are the main tabs to focus on
12:22:53 - Every line under either of those three tabs is an ACL entry (Access Control List)
12:24:06 - Bob's mic just died. Technical difficulties!
12:24:46 - Tip #1 forget about roles all together, don't use them when you are a beginner
12:25:04 - The problem with roles is people think they should have something to do with what users can do. In MODX Revolution Roles have essentially nothing to do with what you can do. The only real reason that you want to have a role most of the time, is so you can give users in the same group different rights. You can just use other groups for this to keep things simpler.
12:26:15 - Bob just uses one role. Role 1 with an authority of 12 (just because he likes that number)
12:27:06 - You give up a little bit of convience by not using roles but hey it's much easier to learn and get things set up without thinking about User Roles
12:27:34 - If you have two different sets of users that you want to have different rights, it probably makes sense for them to be in seperate groups anyways
12:28:02 - If Roles aren't the answer, what does control things?
12:28:20 - A Policy is just a list of individual permissions. If you have the permission checked you get it, if you don't you don't. That's all there is to policies.
12:28:55 - What's a policy template? It's just a list of permissions. There are 162 total, but you can create templates that have only the ones you want to be available to choose from.
12:30:27 - When you have users who can change other users permissions you might want to create a policy template that doesn't have any unnecessary permissions available
12:31:22 - In an old style amusement park you need a specific template to get on each ride. Can't without. That's what MODX permissions are like
12:32:09 - There are context policies and object policies and permissions
12:32:24 - Policy permissions control what you can do in the manager (can you see the elements tree, can you save a resource, etc)
12:33:13 - Bob rewrote part of this speech in his dream last night
12:33:25 - Can I save this resource is a Object Policy question, can I save any resource, that's a context policy question
12:34:48 - There are several 'create' permissions that you can't create anything without
12:35:11 - Let's look at how MODX figures out what permissions you have? Simple case, say you are a member of one user group. When you log in to the manager you are logging into the Manager Context, and MODX checks to see if your User Group has a Context Access ACL for the manager.
12:36:11 - Bob Ray's PC clock says it's 5:37 am
12:39:02 - Whenever you want to do something, ANYTHING, in the manager MODX is going to say "show me your context access ACL checklist". If it's not checked, access denied.
12:40:47 - Permissions only get added, they never get subtracted. Meaning if you belong to multiple User Groups your permissions are combined additively
12:43:44 - Mostly what you are going to use is the Administrator Access Policy or one you created based off it
12:44:47 - Sometimes you want to control what users can do with a specific resource or specific element. That's where object policies come in (this is a great way to protect or hide certain resources and elements from certain users)
12:46:30 - The Object Policy is very small it only has 5 permissions on it Load, List, Save, View and Remove.
12:47:40 - Resource policy is the Object Policy with a few extra things like publish and unpublish
12:47:50 - You have to get passed the Context Permissions to save a document first, before MODX is even going to consider Object policies
12:48:34 - When trying to add a child resource it will first check if the parent is in a Resource Group. Resources not in a Resource Group are unprotected. If it's not protected you can do whatever you want, otherwise it's going to look at Object policies.
12:50:55 - Bob is stopping to talk about protection. (Are we going back to talking about the Red Light District again?)
12:53:45 - In MODX you need permissions to create childreno on protected resources (unlike real life)
12:54:52 - "MODX gives you many many ways to shoot yourself in the foot as you know" - Bob Ray
12:56:30 - If you add resources to a Resource Group that's connecting to the Administrator User Group, all other User Groups will not have access to these resources. In other words, you are protecting them FROM other User Groups without configuring anything specific to any of those User Groups. So if something is protected, unless it's explicity given access to another User Group access will be denied.
(Access is allow/deny in MODx, meaning that access is "open" by default. Once an ACL is applied to an object, such as a Context or Resource Group, those Contexts or Resource Groups will now only be accessible to the objects with appropriate Permissions.)
1:00:15 - Elements work exactly the same way but instead of Resource Groups they are grouped using Categories
1:02:31 - Bob just referred to the the ACL name 'Manager' as 'seductive'
1:06:18 - Remember that when a user visits your site they automatically get access to the (anonymous) User Group meaning that they obtain any ACLs set in that group