MODX Security Diagram

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #1, 15 years, 4 months ago

This is a diagram I’ve came up with on how the different security paradigms link together based on what I know from it.

The idea behind this is to make people understand what all the different terms mean & actually do, to make it easier to understand the existing documentation and find what they are looking for.

Click for larger version.

This is the first version.. please let me know what you think (are there important things missing? did it help you understand it, or not?) - your feedback is very important!

I think this one is different from Goldsky’s cheatsheet (http://modxcms.com/forums/index.php/topic,48252.0.html) in the way that it’s aimed to make people understand the relationships between all the terms.. and not something to refer to when you already understand it, but need some specific info. Though I like the way he relates it to the army. tongue

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

223 Posts

Pleth Reply #2, 15 years, 4 months ago

I think that this could be very useful, would love to see it further developed. Thank you.

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #3, 15 years, 4 months ago

Thanks Greg.

When you say further developed - what are things you would like to see added to this?

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

223 Posts

Pleth Reply #4, 15 years, 4 months ago

I am honestly still struggling with these relationships in Revo. It’s nice to see it visually laid out like this. Since you had requested feedback I was making the assumption that this would likely evolve as others gave their input.

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #5, 15 years, 4 months ago

Ah, okay

Thanks.

If there’s anything specific you’re struggling with do let me/us know - perhaps that can point into the direction needing more attention.

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

150 Posts

goonz39 Reply #6, 15 years, 4 months ago

Very interesting. I haven’t started dabbling in Revo or with Users and Access Permissions yet, but this seems like it should be very useful when that fateful day comes. How relevant is most of this (minus contexts for sure, I know) to Evo?

"Great spirits have always encountered violent opposition from mediocre minds." -Albert Einstein

24,544 Posts

BobRay Reply #7, 15 years, 4 months ago

Very nice. I know how difficult it is to try to explain this stuff. I imagine that took a whole lot of work. wink

I have just a few minor suggestions:

Policy Templates: List of permissions that will appear in the Access Policy

Permissions: Keys whose value determines if a certain action can be performed or not

Change "(higher roles)" to "(roles with higher authority numbers)."

Change "one role per UG" to "one role per user per UG." ?

Maybe expand the brown section at the bottom a little. Something like this:

Resource Group: Resource Group Access ACL entries determine what users can do with resource in the group and whether they can see them or not.

Element Category: Like Resource Group Access but applies to elements (e.g., snippets, chunks, plugins, etc.) in a specific category.

Contexts: The mgr context ACL entries determine what users can do and see in general in the Manager. The web context is the default front-end context, so web Context ACL entries determine what actions the user can perform in the front end with resources in that context. You can create other contexts (usually front-end contexts) with their own ACL entries that determine what users can do with resources in that context.

Note: Even though the web context usually refers to the front end, users in the Manager need a Context Access ACL entry with a context of web in order to see web resources in the tree. They also need a Context Access ACL entry with a context of mgr in order to log in to the Manager.

You might also want to mention under User Group:

(Go to Security->Access Controls->User Groups tab, right-click on a user group and select "Update User Group.")

That place is really hard to find for new users.

Another thought is to put a little orientation at the top along the lines of:

In MODX Revolution, security restrictions are created by assigning users to User Groups and specifying what users in each group can do and see in the Manager and in the front end of the site. Based on the user’s role in the User Group, the user will be assigned a policy, which is a collection of specific permissions that determine what actions the user can perform in a specific context, with resources in a specific resource group, or with elements in a specific category.

It’s your page, so feel free to edit or ignore any of my suggestions. As is, it’s a fantastic resource for the visually inclined

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

20 Posts

barrd Reply #8, 15 years, 4 months ago

Ah... what a great morning

Firstly a huge Thank You to Mark for inspiring me yet again to look at all this, ever so glad to have caught you on Twitter. Secondly, a thanks to the ever wonderful BobRay for his comments too which got me thinking...

Also been reading this article again: http://bobsguides.com/revolution-permissions.html before I step off the edge and delve into the deep waters of MODx ACL understanding.

Looking forward to cracking this.
~Dave

☆ A M B ☆
3,141 Posts

Mark Hamstra Reply #9, 15 years, 4 months ago

Thanks for the comments Bob!

Your article was the best learning source I could find a couple months back for understanding this, so it’s great to hear your feedback

I’ll have to take some time later (probably later this week) to check it out, think about it and change the diagram.

Quote from: goonz at May 07, 2011, 09:03 PM

Very interesting. I haven’t started dabbling in Revo or with Users and Access Permissions yet, but this seems like it should be very useful when that fateful day comes. How relevant is most of this (minus contexts for sure, I know) to Evo?

In all honesty - not at all. Evo could do with its own diagram, though it would be much more simple.

From the top of my mind..

Role = collection of permissions on what you can do in the back-end
Resource groups = same as in Revo, grouping resources together.
Web/manager user groups = a user group which is linked to a resource group they can access, either front- or backend

Probably missing something there, but that’s the gist tongue

Good luck Dave wink

Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.

20 Posts

barrd Reply #10, 15 years, 4 months ago

Thanks Mark,

Looking at it all now and will start a new thread as I have reached as far as I did the last time I attempted this and shall point out some inconsistencies that I have found. The ’concept’ of the ACLs is not beyond me, I have run successful WIki and Drupal installs with complex ACLs, I’m just struggling a bit with the MODx approach and getting it running. All of this of course is meant purely as facts found. I am not in any way pointing fingers or damning anyone, I have nothing but respect for the members here and enjoy the documentation.

~your humble serf
Dave laugh