Chapter 6: My permission control methodology - distributed permission control
Article outline
1. Distributed role permission system
1. Distributed permission control with front-end and back-end separation
2. Front-end multi-terminal distributed permission control
3. Back-end multi-module distributed permission control
2. Distributed credential authority system
No matter which SAAS or management system it is in, the design of permission control is a complex matter.
Let’s first take a look at WordPress’ permission design.
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| create_sites | Y | |||||
| delete_sites | Y | |||||
| manage_network | Y | |||||
| manage_sites | Y | |||||
| manage_network_users | Y | |||||
| manage_network_plugins | Y | |||||
| manage_network_themes | Y | |||||
| manage_network_options | Y | |||||
| upload_plugins | Y | |||||
| upload_themes | Y | |||||
| upgrade_network | Y | |||||
| setup_network | Y | |||||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| activate_plugins | Y | Y (single site or enabled by network setting) | ||||
| create_users | Y | Y (single site) | ||||
| delete_plugins | Y | Y (single site) | ||||
| delete_themes | Y | Y (single site) | ||||
| delete_users | Y | Y (single site) | ||||
| edit_files | Y | Y (single site) | ||||
| edit_plugins | Y | Y (single site) | ||||
| edit_theme_options | Y | Y | ||||
| edit_themes | Y | Y (single site) | ||||
| edit_users | Y | Y (single site) | ||||
| export | Y | Y | ||||
| import | Y | Y | ||||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| install_plugins | Y | Y (single site) | ||||
| install_themes | Y | Y (single site) | ||||
| list_users | Y | Y | ||||
| manage_options | Y | Y | ||||
| promote_users | Y | Y | ||||
| remove_users | Y | Y | ||||
| switch_themes | Y | Y | ||||
| update_core | Y | Y (single site) | ||||
| update_plugins | Y | Y (single site) | ||||
| update_themes | Y | Y (single site) | ||||
| edit_dashboard | Y | Y | ||||
| customize | Y | Y | ||||
| delete_site | Y | Y | ||||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| moderate_comments | Y | Y | Y | |||
| manage_categories | Y | Y | Y | |||
| manage_links | Y | Y | Y | |||
| edit_others_posts | Y | Y | Y | |||
| edit_pages | Y | Y | Y | |||
| edit_others_pages | Y | Y | Y | |||
| edit_published_pages | Y | Y | Y | |||
| publish_pages | Y | Y | Y | |||
| delete_pages | Y | Y | Y | |||
| delete_others_pages | Y | Y | Y | |||
| delete_published_pages | Y | Y | Y | |||
| delete_others_posts | Y | Y | Y | |||
| delete_private_posts | Y | Y | Y | |||
| edit_private_posts | Y | Y | Y | |||
| read_private_posts | Y | Y | Y | |||
| delete_private_pages | Y | Y | Y | |||
| edit_private_pages | Y | Y | Y | |||
| read_private_pages | Y | Y | Y | |||
| unfiltered_html | Y | Y (single site) | Y (single site) | |||
| unfiltered_html | Y | Y | Y | |||
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| edit_published_posts | Y | Y | Y | Y | ||
| upload_files | Y | Y | Y | Y | ||
| publish_posts | Y | Y | Y | Y | ||
| delete_published_posts | Y | Y | Y | Y | ||
| edit_posts | Y | Y | Y | Y | Y | |
| delete_posts | Y | Y | Y | Y | Y | |
| Capability | Super Admin | Administrator | Editor | Author | Contributor | Subscriber |
| read | Y | Y | Y | Y | Y | Y |
Based on user roles and user levels, a hierarchical role authority control system is implemented.
The WordPress permission control system is a very classic permission control system. However, because WordPress is very “lightweight” in terms of users and permissions, the WordPress permission control system can be said to be only a complete “skeleton”. However, it is only Even a skeleton is enough to make many people dizzy.
So, you can imagine how outrageously complex permission control can be in those large and complex systems.
I have worked on many products, covering a wide range of areas. The permission control system is involved in almost every product, so I have accumulated a lot of experience in this area.
I have optimized and simplified various permission control systems countless times. Finally, a simple and effective method was summarized. I call this method: distributed permission control.
The most fundamental reason why permission control is complicated is that centralized permission design, distribution and management force us to consider various roles in various scenarios from a "centralized" perspective. of "can" and "can't".
However, if the distribution and management of permissions are decentralized, everything will become much simpler.
1. Distributed role permission system
Classic permission control systems are centralized role permission systems.
The role permission system has always been the mainstream.
What is introduced here is the distributed role permission system.
Regardless of whether it is centralized or distributed, the role permission system has one thing in common: roles determine permissions, and who determines what capabilities they have.
The distributed role permission system can be divided into three types.
The following content can only be viewed by VIP users.
Subscribe to my VIP membership and you can read all paid VIP content.
If you are already a VIP member, please log in.