Only the backend is involved, see the top column for all directories, codes, documents, and interface paths are:
[Lilishop Mall] Record the study notes of the B2B2C mall system~
The whole article will combine the business introduction to focus on the design logic, including the interface class and business class. The specific combination of source code analysis is not complicated to read~
Caution: Some comments in the source code are wrong, some comments have completely opposite meanings, and some comments are not correct. I updated them during the reading process and added new comments where I did not know. So be careful when reading the source code!
Table of contents
A1. Operation user module (only for M terminal operation)
B1. Design logic analysis (you can skip it if you are familiar with it)
B2. Request interface analysis
B3. Business Analysis Description
C2. Authentication authentication
A1. Operation user module (only for M terminal operation)
The framework design of user login and authentication has been described in the system construction before [Lilishop Mall] No2-2. Determine the software architecture construction 1 (this article includes MVC framework, persistent framework, cache, authentication tools, security framework, etc.)
Among them are the public classes in the framework module, as well as the login and authentication classes of each end. Here we will briefly mention it again, focusing on operating the user's business.
The operating user module in the shop system is the same as most systems, it is nothing more than user-menu-department-role, the user's authority is determined by the role, and the role is associated with the menu (menu means authority).
Next, we will design in detail from three aspects, first analyze the business logic, then disassemble the business operation into specific call interfaces, and then analyze the specific business class (the business class can also be analyzed in the coding stage, our current The detailed design only includes the interface and design logic, not including the business class), and remember to analyze it in combination with each end~
B1. Design logic analysis (you can skip it if you are familiar with it)
I won’t go into details about the logic that can be seen at a simple glance, such as adding and modifying users, but the permissions involved in users are implicit content, which needs to be explained.
C1. User
It is mainly to manage users; users will be associated with roles and departments, and users will only be associated with one department, but can be associated with multiple roles; when adding users, the user name and mobile phone number are not verified; there is nothing to say about the rest.
C2.Department
Mainly manage departments; departments adopt cascading, and each department will have a superior department id; departments will be associated with roles; there is nothing to say about the rest.
C3. Menu
It is mainly the management menu; the routing name needs to be unique and used for the front end; the authority url collection is used for the back end; there is nothing to say about the rest.
C4. Role
The main thing is to manage roles; the roles will be associated with the menu; the rest is nothing to say.
C5. Login/logout
This logic has been mentioned before, 1. When the user logs in, an accesstoken is generated and cached for 60 minutes, the permission list is obtained and cached indefinitely, and finally the accesstoken is returned. 2. When the user accesses with an accesstoken, first determine whether the accesstoken exists, if it exists, it is valid, then get the permission list from the cache and generate an AuthenticationToken, and then authenticate; if it does not exist, it will directly throw an exception and return. 3. When the user logs out, delete the accestoken directly from the cache;
Personal supplements:
1. In the shop system, when editing a user, the permissions in the cache are not updated, which will cause the user permissions to be updated, and the new permissions of the user need to log in again to take effect. If the accestoken logged in by the user can be automatically updated, it may cause the new user permissions to fail to take effect (although the accestoken is not automatically updated).
Originally, I was thinking of clearing the cache and re-updating when editing a user. Later, I thought that when updating role permissions and updating department roles, user permissions will be affected. I can’t clear everything, so I saw the update token in the system Interface, why not just add it here, although it will not be updated in real time, but the failure will not be too long. Then look at the code and find that the system is like this~
2. When adding/registering a user, the user name and mobile phone number are not verified, which must be verified
3. The permission of the shop system is unreasonable here. The permission is only the operation permission and the viewing permission, and it will not be accurate to the button, and the front end does not make the button explicit/hidden for the permission, that is, the menu authentication. There are front and back ends, and the buttons only have back-end authentication, and the front-end will display whether they have permissions or not! very not recommended
B2. Request interface analysis
Under normal circumstances, the input and output parameters of the interface must be clearly written before development. For example, ApiFox can be used for management, so that the front-end and back-end docking will be very coordinated. If it involves testing, it will be written in ApiFox. Here I am I won’t write detailed entry and exit references, see the top for the detailed api public link~
C1. User & Login/Logout
- User's multi-condition pagination to obtain user list, add user, edit user, delete user, disable/enable, reset password;
- Edit and modify the password of the current user;
- User login, logout, update token;
- get cascaded list of departments (see department module);
- Acquisition list of roles (see role module);
In addition to basic data, there are AdminUserDTO and AdminUserVO for input parameters. DTO is used to receive input parameters, and VO is used to output parameters. Entity classes are not used because the content contained in the entities is not suitable for use, and the second is that the output parameters may contain sensitive information;
C2.Department
- Department View details of a single department, get a cascading list, add a department, edit a department, delete a department;
- Department-Role View the list of roles owned by the department, and update the role of the department (see the department-role module);
- Acquisition list of roles (see role module);
In addition to the basic data, the input parameters also include Department, which is the entity class
C3. Menu
- Get cascading list of menus, get current user permissions, get search menu list, add menu, edit menu, delete menu;
In addition to basic data, there is also MenuVO
C4. Role
- Get the role paging list of roles, add roles, edit roles, delete roles;
- Role-menu View A certain role has to the menu, save the role menu; (see role-menu module)
In addition to the basic data, the input parameters also include Role, which is the entity class
C5. Department-Role
- Department-Role View the list of roles owned by the department and update the roles of the department;
In addition to the basic data, the input parameters also include DepartmentRole, which is the entity class
C6. Role - Menu
- Role-menu view A certain role has to the menu, save the role menu;
In addition to the basic data, there is also RoleMenu, which is the entity class
B3. Business Analysis Description
It is a business description added for complex operation/request interfaces. For example, in the edit department interface, it is also necessary to call the update department role interface, which needs to be explained. Not every interface will be given.
The business class here has no complicated logic.
C1. Association class
Role-menu, department-role, these two association classes need to be given interfaces, and they need to be called in conjunction with the business.
The role-user association class does not use the request interface, because it operates directly in the business requested by the user.
C2. Authentication authentication
After the user logs in, he gets the accesstoken, and then gets the current user permission (that is, the menu permission), and then the front-end displays the menu according to this. Then when the user clicks the button, the interface will be called, and the backend will first judge whether the permission URL in the user's permission list can match the request path. If it cannot match, it will directly return insufficient permission.
[So the authentication is matched by PatternMatch, and the permission url in the menu table must correspond to the request url of the interface! ! ! I personally think that this kind of logic is actually not very good, you can look at the logic of pig and Ruoyi]