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
B1.S terminal (belongs to explicit operation)
B2. Clerk user rights (belonging to business)
A1. Store clerk
The store will be bound to a member as the owner, and the store can choose multiple members to be the clerk through the mobile phone number, but the member can only be a store owner or a clerk on the S terminal, that is, it can only belong to one store.
The store information opened by the current member will be stored in the li_member membership table;
The li_clerk clerk table will store the members added by the store; and the clerk must be unique in this table;
The li_store store table will store the store owner's membership information;
This storage will be more convenient in use; because the binding between members and stores will not be easily changed
B1.S terminal (belongs to explicit operation)
The authority management of shop assistants is similar to that of operations, including shop assistants (users), departments, and roles, except that the menu permissions on the S side are directly managed by the operation side (currently, there is a management interface for Miyou), and the most important things are shop assistants, departments, and roles. And role-menu association will be associated with a store id.
There are corresponding operation pages for clerks, departments, and roles, so there must be corresponding interface controllers.
Department-role and role-menu are association tables, which belong to the related operations of department and role pages respectively. On the department page, the editor of the department and the editor of the department-role are edited separately, so here the association table is also drawn into a controller
C1. Clerk
The clerk here is also added, checked, modified, and deleted. The addition of a clerk here will be related to the B-side member's application for store entry, which means that judgment will be made when adding a clerk. If the member already has a store or is already a clerk of another store, he cannot be added as a clerk (judged by the mobile phone number)
1. After the store owner successfully adds a member who has no store and is not a clerk as a clerk: the clerk can no longer be added as a clerk by other stores on the S side. It will prompt that you cannot apply)
2. Members without stores and non-store assistants are applying for store entry review or after the review fails: the member can be added as a store clerk by other stores on the S side, or continue to apply for store entry on the B side, but the two are mutually exclusive. Only one will succeed in the end.
3. After the member who has no store and non-store clerk applies for store entry and is approved: the member can no longer be added as a store clerk by other stores on the S side, and can no longer apply for store entry on the B side
- Get the list of clerks by page, get the details of clerks, check the validity of mobile phone numbers, add clerks, modify clerks, ban/enable clerks, delete clerks, reset passwords
Because the clerk-role association is added and changed along with the clerk, and there is no operation to obtain the associated information separately, so there is no user-role association table interface controller, and there will be associated services~
C2.Department
The logic here is similar to the operation
- Get tree structure, add department, update department, delete department, view department details
- View the roles owned by the department and update the department roles (see department-role)
C3. Role
- Add roles, query store roles by page, edit store roles, delete store roles in batches
- View menus owned by a character, save character menus (see Characters - Menus)
C4. Menu
You only need to check it. Of course, if you need dynamic management, you can add this interface on the operation M side.
- Get all menus, get all menus --- according to the current user role
C5. Department-Role
Here is the association table. When updating, remember to clear the existing ones and then add them~
- View the roles owned by the department and update the department roles
C6. Role - Menu
Here is the association table. When updating, remember to clear the existing ones and then add them~
- View menus owned by a character, save character menus (see Characters - Menus)
B2. Clerk user rights (belonging to business)
This is not an interface, but a business logic.
Now there are three terminals, except for the B terminal, which has login authentication (B terminal can also be added). The authentication authentication has two points: authentication only when logging in, and authentication when carrying a token.
Because the user entities are different, one is a member, and the other is an operation user AdminUser. In order to use unified authentication and authentication tools (TokenUtil, AuthenticationFilter) on the M-side and S-side, we use a unified logic: cache user login information and permissions when logging in List, when accessing with token, it is intercepted by the filter, and the user information and permission list are obtained from the buffer and encapsulated into UsernamePasswordAuthenticationToken. This can be used uniformly.
You can look at the following classes, taking store login as an example:
//以店铺端登录为例
//店铺登录接口
cn.lili.controller.passport.StorePassportController#userLogin()
//店铺登录业务方法
cn.lili.modules.member.serviceimpl.MemberServiceImpl#usernameStoreLogin()
//店铺生成token方法，在这个里面缓存权限
cn.lili.modules.member.token.StoreTokenGenerate#createToken()
//工具类tokenutil，在这里缓存token
cn.lili.common.security.token.TokenUtil#createToken()
//店铺security过滤器，在这个里面获取缓存中的token和权限进行处理~
cn.lili.security.StoreAuthenticationFilter
The specific code business logic will be explained in detail later.