Roles and the permission model
One permission table carries directories, menus, buttons and endpoints; multi-role RBAC; annotations are the single source of truth.
The model
One permission table carries four kinds of node — directory / menu / button / endpoint — and users relate to roles many-to-many. A button and the endpoint behind it share the same permission code, with no mapping configuration in between.
| Table | Role |
|---|---|
sys_user | user master table, the root of the permission system |
sys_role | roles |
sys_user_role | many-to-many relation between users and roles |
sys_permission | permission-code contract layer: buttons and endpoints |
sys_role_permission | grants between roles and permission codes |
sys_menu | presentation layer: visibility and order of directories and menus |
sys_user_identity | third-party identities (WeChat unionid/openid, QQ openid) |
Tip: permission codes are the contract layer; menus are only the presentation layer. Visibility is decided by permission codes; menus decide where it sits and in what order.
Authorization
@SaCheckPermissionon the server is the single source of truth; the front end only shows and hides, it never decides permissions.- Deny by default: an endpoint without an auth annotation fails at startup. It never silently becomes a public endpoint.
- Not signed in returns a fixed error code; lacking permission returns the fixed permission code — never the "system busy" fallback.
Ways to sign in
- Account and password: BCrypt is the fixed password scheme, no weak-hash option is offered.
- Email code: codes use
SecureRandom, and sending is confined toinfra/mail. - Third-party login: WeChat and QQ are abstracted behind one identity interface, with no extra security framework.
Related
Last updated 2026-10-09Edit this page →