# SpringBoot-Shiro-Vue: permission checks at the button and API level

> A reference implementation that splits permission enforcement between a Spring Boot backend and a Vue frontend. The README describes a v2.0.0 rewrite that removed the Shiro dependency in favour of a custom annotation plus AOP, and the repository still carries the Shiro name.

**Heeexy/SpringBoot-Shiro-Vue** — 提供一套基于Spring Boot-Shiro-Vue的权限管理思路.前后端都加以控制,做到按钮/接口级别的权限。（当前新版本已移除shiro依赖，简化了配置）

- Repository: https://github.com/Heeexy/SpringBoot-Shiro-Vue
- Stars: 4,655 · Forks: 1,755
- Language: Java
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/heeexy-springboot-shiro-vue

## The problem: role checks that break as soon as an admin edits a role

Most permission designs go user to role to permission, and the README argues that is the wrong place to enforce anything. Roles are configured by whoever runs the system, not by the people writing the code, so a single user can hold several roles and any role can hold any number of permissions. If the backend validates roles, every deployment has to reason about combinations that did not exist when the code was written. The project's answer is stated plainly in the README: the backend interface only validates permissions, not roles. Roles exist to group permissions for assignment in the admin UI. Verification asks whether the caller holds article:add, never whether the caller is a manager. The intended audience is a team building an internal admin console on Spring Boot with a Vue frontend, where the same screen has to show different buttons to different people. That is a narrower audience than a general-purpose auth library, and the README treats the project as a design proposal you adapt rather than a dependency you add.

## Backend enforcement: a custom annotation and AOP instead of Shiro

The original design annotated controller methods with Shiro's @RequiresPermissions("article:add") rather than @RequiresRoles. The v2.0.0 entry in the update log, dated 2021.05.09, says the project replaced Shiro's functionality with a custom annotation plus AOP, simplifying configuration and, in the README's words, improving extensibility. The same entry says tokens replaced sessions as the login credential, which removes the cross-origin problem that session cookies create when the Vue dev server and the API run on different origins. A second change in that release is support for one user holding multiple roles. The repository layout backs the claim up: the back/ directory holds the Spring Boot application and the README no longer describes a Shiro configuration block. What the README does not document is the annotation's own name, its parameters, or how the AOP advice resolves a token to a permission list. That code lives in back/ and has to be read directly. Treat this as a sketch of an enforcement layer, not a finished one: there is no stated handling for permission caching, token expiry, or refresh.

## Frontend enforcement: menuList builds routes, permissionList builds buttons

The frontend is built on vueAdmin-template and ElementUI, and the README says the dynamic route design follows vueAdmin's approach. The backend's job is security; the frontend's stated job is only to hide menus and buttons the user cannot use. On login the API returns a userPermission object containing menuList, permissionList, roleId, roleName, nickname and userId. menuList decides which routes are generated for that user. permissionList decides which buttons render and, by extension, which requests the UI is willing to make. The README's example payload contains menuList entries "role", "user" and "article", and permissionList entries "article:list", "article:add" and "user:list". Note the asymmetry: menuList carries menu names, permissionList carries resource:action strings. Hiding a button is cosmetic and trivially bypassed by anyone with a console, which is exactly why the README insists the backend does the real check. If you copy the frontend pattern without the backend annotation, you have built a UI that lies about its own security.

## Install and first run: back/, vue/ and db.sql

The README gives one install path, for the frontend, inside the vue folder. From the repository root, change into vue and run the two npm commands. The README does not describe a build step for back/ beyond calling it a normal Spring Boot application, and it does not list a JDK or Maven version, so those come from whatever the pom in back/ declares.

```bash
cd vue
npm install
npm run dev
```

After npm run dev the dev server prints a local URL, and the app loads the login screen. The demo credentials published in the README are admin with password 123456, described there as an administrator login that can add users and roles. The backend must be running and reachable from that dev server, and the README does not spell out the API port or a proxy configuration, so check the Vue project's own config for the base URL before assuming the login request will land.

The database is not created by the application. The repository root contains db.sql, which holds the schema and seed data, and the README shows a permission detail table that lists every permission the system knows about, plus a second table of permission data. Import db.sql into your database first, then start the backend. The README's rule is that a user holding the first five permissions in that table resolves to the article and user menus, with button visibility following from the same permission list. If your permission table is empty, expect a login that succeeds and a UI with no menus.

## What the repository does not give you

There are no releases. The update log in the README jumps straight from the heading to v2.0.0, and the versioning is documentation, not published artifacts, so there is nothing to depend on from a package repository. The last push to master was on 2026-05-07, which is recent enough that the code is not abandoned, but a project can be pushed to without being maintained in the sense a team needs: no changelog beyond that one entry, no migration notes, and no visible triage of incoming issues. The README also leaves several things unsaid that matter in production. Token expiry and revocation are not described. Permission changes take effect at login, because the payload is fetched then; the README does not say what happens to an already-open session when an admin removes a permission. The demo site at g.heeexy.com is referenced as a test address, and the README does not state whether it is kept in sync with master. This is a teaching repository. Reading it takes an afternoon; expecting it to behave like a library will take longer than that.

## How this differs from Spring Security and from Shiro itself

The obvious alternative is Spring Security, which is the default for Spring Boot applications and offers method security through its own annotations. The difference in approach is where the permission data lives. Spring Security gives you the enforcement mechanism and expects you to supply an expression handler and a source of authorities; this project supplies the whole chain end to end, including the annotation, the AOP advice, the token login, the permission table and the Vue route generation. That is more opinionated and much smaller. It also means the project inherits none of Spring Security's audit history, integration surface or documentation. The second alternative is Shiro, which this project used and then removed. Shiro is a general security framework with realms, sessions and its own filter chain; the v2.0.0 change traded that for a custom annotation and stateless tokens. If you want a framework with a specification and a release cadence, Shiro or Spring Security is the answer. If you want to see one complete, readable path from a database permission row to a hidden button, this repository is the shorter read.

## Licence and the cost of staying current

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. The LICENSE file sits at the repository root. Two practical notes follow from that, without straying into legal advice. First, MIT gives you no warranty, so any production use is your risk. Second, because there are no releases and no versioned artifacts, upgrades are not a matter of bumping a dependency coordinate. You either copy files into your own project or track master and diff it yourself. That makes the real maintenance cost the cost of reading Java and Vue rather than the cost of a version bump. If your team cannot comfortably read the AOP advice in back/ and the route generation in vue/, adopting this means owning code you do not fully understand.

## Conclusion

Adopt it if you are building a Spring Boot and Vue admin panel and want a worked example of permission-only checks with a menuList and permissionList payload driving the UI. Do not adopt it if you need a maintained library, a published artifact, or anything resembling an upgrade path; the last push was on 2026-05-07 and there are no releases. Before writing any code, read back/src for the custom annotation and AOP classes that replaced Shiro, check db.sql for the permission table shape your own data must match, and confirm the token scheme in the README's v2.0.0 notes matches how your frontend stores credentials.

## FAQ

### Does SpringBoot-Shiro-Vue still use Shiro?

No. The README's v2.0.0 entry, dated 2021.05.09, says the project replaced Shiro's functionality with a custom annotation plus AOP, simplifying configuration and improving extensibility. The repository name still carries Shiro, which is where the confusion comes from.

### How do I run the frontend of SpringBoot-Shiro-Vue?

The README gives two commands from the vue folder: npm install and npm run dev. The backend is not covered by those commands and has to be started separately from back/.

### What are the demo login credentials for SpringBoot-Shiro-Vue?

The README lists admin with password 123456 at the test address g.heeexy.com, described there as an administrator login that can add users and roles. It does not say whether that demo site tracks the master branch.

### Does SpringBoot-Shiro-Vue check roles or permissions on the backend?

Permissions only. The README states that backend interfaces validate permissions and not roles, and that roles exist to manage the assignment of permissions. The example annotation is @RequiresPermissions("article:add").

### Is SpringBoot-Shiro-Vue still maintained?

The repository is not archived and the last push to master was on 2026-05-07. There are no releases and the README's update log contains a single v2.0.0 entry, so there is no published upgrade path.

## Sources

- [Heeexy/SpringBoot-Shiro-Vue on GitHub](https://github.com/Heeexy/SpringBoot-Shiro-Vue)
- [Issues](https://github.com/Heeexy/SpringBoot-Shiro-Vue/issues)
- [License: MIT](https://github.com/Heeexy/SpringBoot-Shiro-Vue/blob/master/LICENSE)
- [README](https://github.com/Heeexy/SpringBoot-Shiro-Vue/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/heeexy-springboot-shiro-vue