Source code courseware sharing of practical videos on ThinkPHP development of large-scale shopping mall projects

ThinkPHP is an open source PHP framework that was born to simplify enterprise-level application development and agile WEB application development. It was first born in early 2006, formerly known as FCS. It was officially renamed ThinkPHP on New Year's Day 2007, and was released under the Apache2 open source agreement. The early ideological architecture originated from Struts. Later, after continuous improvement and improvement, it also learned from many excellent foreign frameworks and models, using object-oriented development structure and MVC model, integrating Struts' Action and DAO ideas and JSP's TagLib ( Tag library), RoR's ORM mapping and ActiveRecord mode, which encapsulates CURD and some common operations, single entry mode, etc., has unique performance in template engine, caching mechanism, authentication mechanism and scalability

Course broadcast address: http://www.php.cn/course/350.html

The teacher's teaching style:

The lectures are friendly, natural, and unpretentious. They are not pretentious or deliberately exaggerated, but talk eloquently and carefully. There is a kind of equality between teachers and students. In a , collaborative and harmonious atmosphere, silent emotional exchanges are carried out, and the desire and exploration of knowledge are integrated into simple and real teaching situations. Students gain knowledge in quiet thinking and silent approval

The more difficult point in this video is the introduction of ThinkPHP-RBAC:

RBAC is the acronym for Role-Based Access Control, which is translated into Chinese as role-based access control. To put it bluntly, users are associated with roles and permissions [its architecture is inspired by the permission management control of the operating system's GBAC (GROUP-Based Access Control)]. Simply put, a user can have several roles, and each role has several permissions. In this way, a "user-role-permission" authorization model is constructed. In this model, there is generally a many-to-many relationship between users and roles, and between roles and permissions.

In many practical applications, the system not only requires users to complete simple registration, but also requires different levels of users to access different resources. Have different operating permissions. And in enterprise development, the rights management system has become one of the most efficient modules for repeated development. In multiple systems, the corresponding permission management can only meet the management needs of the own system, and may be different in terms of database design, permission access and permission management mechanisms. This inconsistency also has the following consequences:

Maintaining multiple systems, reinventing the wheel repeatedly, time is wasted on the cutting edge

User management, organizational mechanism and other data are repeatedly maintained, and the integrity and consistency of the data are difficult to guarantee

Different permission system designs, different conceptual understandings, and corresponding technical differences, there are problems with integration between systems, single sign-on is difficult, and complex enterprise systems also bring difficulties

RBAC is based on continuous practice After that, a relatively mature access control scheme was proposed. Practice has shown that using a permission management system based on the RBAC model has the following advantages: Since changes between roles and permissions are relatively much slower than changes between roles and user relationships, the complexity of authorization management is reduced and management overhead is reduced. ; And it can flexibly support the security policy of the application system and has great scalability to changes in the application system; In terms of operation, permission distribution is intuitive, easy to understand, and easy to use; hierarchical permissions are suitable for hierarchical user-level forms; reuse Strong sex.

RBAC implementation system in ThinkPHP

The RBAC in ThinkPHP is based on Java's Spring's Acegi security system as a reference prototype, and has been simplified accordingly to adapt to the current ThinkPHP structure and provide a more A layered, customizable security system to provide security control for application development. The security system mainly has the following parts:

Security Interceptor

Authentication Manager

Decision Access Manager

Running Identity Manager

Security Interceptor

Security interceptor is like a door. There may be many different security control links in the system's security protection system. Once you fail to pass the security system certification in a certain link, then the security interceptor will The server will intercept it.

Authentication Manager

The first door of the protection system is the authentication manager. The authentication manager is responsible for determining who you are. Generally, it verifies your subject (usually a user name) and your credentials (usually a password), or more information to do this. To put it more simply, the authentication manager verifies that your identity is within the authorization scope of the security protection system.

Access decision management

Although you have passed the authentication of the authentication manager, it does not mean that you can do whatever you want in the system, because you still need to access the decision management door. The access decision manager authorizes users and determines whether you can enter a certain module of the system and perform a certain operation by considering your identity authentication information and the security attributes associated with the protected resources. For example, if the security rules stipulate that only supervisors are allowed to access a certain module, and you are not granted supervisor permissions, the security interceptor will intercept your access operation.
The decision-making access manager cannot run alone and must first rely on the authentication manager for identity confirmation. Therefore, the authentication manager and decision-making access manager are already included when loading the access decision filter.
In order to meet the different needs of applications, ThinkPHP adopts two modes when conducting access decision management: login mode and instant mode. In login mode, the system reads and changes the user's authorization information to the Session when the user logs in, and does not re-obtain the authorization information next time. That is to say, even if the administrator makes permission modifications to the user, the changes will only take effect after the user logs in next time. The immediate mode is to solve the above problem. Every time a module or operation of the system is accessed, it is immediately verified whether the user has the authorization for the module and operation, thus ensuring the security of the system to a higher degree.

Running Identity Manager

The usefulness of Running Identity Manager is limited in most application systems. For example, a certain operation and module requires the security requirements of multiple identities. Running Identity Manager You can replace your current identity with another identity, allowing you to access protected objects deeper within the application system. This layer of security system is not currently implemented in RBAC.

RBAC authentication process in ThinkPHP

Corresponding to the above security system, the process of ThinkPHP's RBAC authentication is roughly as follows:

Determine whether the current operation of the current module requires authentication

If authentication is required and you have not logged in, jump to the authentication gateway. If you are already logged in, execute 5

User identity authentication through delegated authentication

Get the user's decision-making access list

Determine whether the current user has access permissions

The specific implementation process of permission management

Introduction to RBAC-related databases

The ThinkPHP complete package includes the RBAC processing class RBAC.class .php file, located in Extend/Library/ORG/Util. Open the file, which contains the four tables necessary to use RBAC. The SQL statements are as follows (please replace the table prefix after copying):

CREATE TABLE IF NOT EXISTS `ly_access` (
  `role_id` smallint(6) unsigned NOT NULL,
  `node_id` smallint(6) unsigned NOT NULL,
  `level` tinyint(1) NOT NULL,
  `module` varchar(50) DEFAULT NULL,
  KEY `groupId` (`role_id`),
  KEY `nodeId` (`node_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `ly_node` (
  `id` smallint(6) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  `title` varchar(50) DEFAULT NULL,
  `status` tinyint(1) DEFAULT '0',
  `remark` varchar(255) DEFAULT NULL,
  `sort` smallint(6) unsigned DEFAULT NULL,
  `pid` smallint(6) unsigned NOT NULL,
  `level` tinyint(1) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `level` (`level`),
  KEY `pid` (`pid`),
  KEY `status` (`status`),
  KEY `name` (`name`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8;
 
CREATE TABLE IF NOT EXISTS `ly_role` (
  `id` smallint(6) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  `pid` smallint(6) DEFAULT NULL,
  `status` tinyint(1) unsigned DEFAULT NULL,
  `remark` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `pid` (`pid`),
  KEY `status` (`status`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 ;
 
CREATE TABLE IF NOT EXISTS `ly_role_user` (
  `role_id` mediumint(9) unsigned DEFAULT NULL,
  `user_id` char(32) DEFAULT NULL,
  KEY `group_id` (`role_id`),
  KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Here we also recommend downloading source code resources: http://www.php.cn/xiazai/learn/2134

Material

Documentation

Source code

Illustration

Template

The above is the detailed content of Source code courseware sharing of practical videos on ThinkPHP development of large-scale shopping mall projects. For more information, please follow other related articles on the PHP Chinese website!