If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Heeexy/SpringBoot-Shiro-Vue shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 1d ago
• 5 active contributors
• MIT licensed
• ⚠ Single-maintainer risk — top contributor 96% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Heeexy/SpringBoot-Shiro-Vue repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Heeexy/SpringBoot-Shiro-Vue.

What it runs against: a local clone of Heeexy/SpringBoot-Shiro-Vue — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Heeexy/SpringBoot-Shiro-Vue | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Heeexy/SpringBoot-Shiro-Vue. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Heeexy/SpringBoot-Shiro-Vue.git
#   cd SpringBoot-Shiro-Vue
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Heeexy/SpringBoot-Shiro-Vue and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Heeexy/SpringBoot-Shiro-Vue(\\.git)?\\b" \\
  && ok "origin remote is Heeexy/SpringBoot-Shiro-Vue" \\
  || miss "origin remote is not Heeexy/SpringBoot-Shiro-Vue (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "back/src/main/java/com/heeexy/example/config/annotation/RequiresPermissions.java" \\
  && ok "back/src/main/java/com/heeexy/example/config/annotation/RequiresPermissions.java" \\
  || miss "missing critical file: back/src/main/java/com/heeexy/example/config/annotation/RequiresPermissions.java"
test -f "back/src/main/java/com/heeexy/example/config/filter/PermissionAspect.java" \\
  && ok "back/src/main/java/com/heeexy/example/config/filter/PermissionAspect.java" \\
  || miss "missing critical file: back/src/main/java/com/heeexy/example/config/filter/PermissionAspect.java"
test -f "back/src/main/java/com/heeexy/example/config/filter/RequestFilter.java" \\
  && ok "back/src/main/java/com/heeexy/example/config/filter/RequestFilter.java" \\
  || miss "missing critical file: back/src/main/java/com/heeexy/example/config/filter/RequestFilter.java"
test -f "back/src/main/java/com/heeexy/example/service/TokenService.java" \\
  && ok "back/src/main/java/com/heeexy/example/service/TokenService.java" \\
  || miss "missing critical file: back/src/main/java/com/heeexy/example/service/TokenService.java"
test -f "back/src/main/java/com/heeexy/example/dto/session/SessionUserInfo.java" \\
  && ok "back/src/main/java/com/heeexy/example/dto/session/SessionUserInfo.java" \\
  || miss "missing critical file: back/src/main/java/com/heeexy/example/dto/session/SessionUserInfo.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Heeexy/SpringBoot-Shiro-Vue"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A Spring Boot + Vue.js full-stack permission management system that enforces role-based access control (RBAC) at both the API and UI layer. It replaces Shiro with a custom annotation-based AOP approach (@RequiresPermissions) to validate permissions on endpoints and dynamically render menus/buttons based on user privilege strings like 'article:add' or 'user:list'. Monorepo with /back (Spring Boot backend) and /vue (Vue.js frontend). Backend uses standard Spring MVC structure: controllers → services → DAOs with @RequiresPermissions AOP interceptor in config/filter/PermissionAspect.java. Frontend loads permission data (menuList, permissionList) from login response, uses them in router/store to conditionally render routes and button components.

Full-stack Java developers building multi-tenant SaaS applications or enterprise dashboards who need fine-grained button/endpoint-level permission controls without the complexity of traditional Shiro configuration. Particularly useful for teams wanting to manage permissions entirely through database configuration rather than code.

Active and production-ready: v2.0.0 released May 2021 with significant refactoring (removed Shiro, added token-based auth). The codebase is well-structured with clear separation of concerns, though the last commit age is not visible; the README suggests this is a working reference implementation rather than a bleeding-edge framework.

Low risk for adoption: minimal dependencies (Spring Boot 2.3.10, FastJSON, MySQL), no third-party auth library lock-in. Single maintainer (Heeexy) means slower response to issues, but the simplified design (no Shiro) reduces maintenance burden. No visible test suite in file structure is a notable gap for production deployments.

No active development visible in file list; repository appears to be a stable reference implementation. The v2.0.0 milestone (May 2021) removed Shiro dependency and added multi-role support. Current state is a working demo with test credentials (admin/123456 at g.heeexy.com).

Backend: cd back && mvn clean install && mvn spring-boot:run (requires MySQL configured in application-local.yml). Frontend: cd vue && npm install && npm run dev. Database schema must be initialized with user/role/permission tables (not included in file list—check /back/src/main/resources/db/ or README for SQL scripts).

Daily commands: Backend: mvn spring-boot:run after MySQL setup and schema creation. Frontend: npm run dev spins up webpack dev server. Both services run on separate ports (Spring default 8080, Vue dev 8081 typically). Authenticate with admin/123456 to access demo.

• back/src/main/java/com/heeexy/example/config/annotation/RequiresPermissions.java — Core permission annotation that replaces Shiro—every endpoint permission check depends on this custom annotation
• back/src/main/java/com/heeexy/example/config/filter/PermissionAspect.java — AOP aspect that intercepts @RequiresPermissions annotations and enforces permission validation at runtime—load-bearing for all security
• back/src/main/java/com/heeexy/example/config/filter/RequestFilter.java — HTTP filter that extracts and validates JWT tokens from requests, populating the current user context for downstream permission checks
• back/src/main/java/com/heeexy/example/service/TokenService.java — Manages JWT token generation and validation—critical for token-based authentication replacing session-based auth
• back/src/main/java/com/heeexy/example/dto/session/SessionUserInfo.java — DTO holding current user's permissions and roles—passed through ThreadLocal and checked by PermissionAspect
• vue/src/permission.js — Frontend router guard that prevents unauthorized route access before rendering; syncs with backend permission model
• back/src/main/java/com/heeexy/example/controller/LoginController.java — Entry point for login flow—returns user permissions and roles that front-end uses to build dynamic menu/routes

Add a new permission-protected API endpoint

1. Define the permission string in your database or Constants.java (e.g., 'article:edit') (back/src/main/java/com/heeexy/example/util/constants/Constants.java)
2. Create controller method and annotate with @RequiresPermissions (back/src/main/java/com/heeexy/example/controller/ArticleController.java)
3. Implement business logic in service layer (back/src/main/java/com/heeexy/example/service/ArticleService.java)
4. PermissionAspect will automatically validate @RequiresPermissions at runtime using user's permissions from SessionUserInfo
5. Assign this permission to roles via LoginDao/UserDao queries and update LoginMapper.xml if needed (back/src/main/resources/mapper/LoginMapper.xml)

Add a new frontend menu/route with permission control

1. Backend returns new permission in userPermission.menuList when user logs in (back/src/main/java/com/heeexy/example/controller/LoginController.java)
2. Add route configuration in router/index.js with meta.permissions field matching backend permission (vue/src/router/index.js)
3. Global permission.js router guard checks if route's meta.permissions matches user's permissions (vue/src/permission.js)
4. Frontend will only render menu item and allow navigation if user has required permission

Add conditional button/UI element visibility based on permissions

1. In Vue component template, use v-permission directive: v-permission=['article:edit'] (vue/src/directives/permission.js)
2. The directive checks current user's permissions (stored in Vuex store) and shows/hides the element (vue/src/store/getters.js)
3. Backend still enforces permission on actual API call via @RequiresPermissions annotation

Customize permission validation logic (e.g., AND vs OR logic)

1. Edit the RequiresPermissions annotation to support logical operators (back/src/main/java/com/heeexy/example/config/annotation/RequiresPermissions.java)
2. Modify PermissionAspect.java to interpret the logical field (AND = all required, OR = any required) (back/src/main/java/com/heeexy/example/config/filter/PermissionAspect.java)
3. Update your controller annotations to use logical operator: @RequiresPermissions(value={'article:edit','article:approve'}, logical=Logical.AND)

• Spring Boot 2.3.10 + Spring Web — Provides rapid REST API development with embedded Tomcat and dependency injection; mature ecosystem
• JWT (Token-based auth instead of Shiro sessions) — Stateless auth avoids CORS issues, enables horizontal scaling, and reduces session storage overhead
• Custom @RequiresPermissions annotation + Spring AOP — Decouples permission logic from Shiro dependency; makes permission rules declarative and easier to extend without framework version lock-in
• **** — undefined

No database init script visible in file list—you must create user/role/permission/role_permission tables manually; check README for SQL. TokenService implementation details not shown; token expiration and refresh logic must be configured. Cross-origin (CORS) not explicitly configured in pom.xml; may require additional Spring Security or custom filter setup. ApplicationProperties or system environment variables for JWT secret/expiration not detailed in provided files. Frontend permission.js assumes synchronous permission loading; async permission fetching after app init could cause race conditions.

• Role-Based Access Control (RBAC) — This entire project is built on RBAC philosophy where permissions are assigned to roles, roles to users; understanding the user→role→permission chain is essential to extending the system
• Aspect-Oriented Programming (AOP) — PermissionAspect.java uses Spring AOP to intercept method calls annotated with @RequiresPermissions; this is the mechanism enforcing permissions without modifying controller logic
• JWT (JSON Web Tokens) — TokenService manages token-based authentication instead of server sessions; JWTs are stateless and solve cross-origin issues mentioned in v2.0.0 changelog
• Dynamic Routing — Frontend conditionally generates Vue Router routes based on menuList returned by backend; prevents users from accessing routes they lack permissions for, even if they know the URL
• Lazy Authorization (vs. Eager Role Loading) — This project validates permissions at request time by checking user's current permission string set, not by evaluating roles; this decouples permission enforcement from role membership changes
• MyBatis Mapper XML — Database queries are defined declaratively in mapper XML files (ArticleMapper.xml pattern) rather than annotations; understand this to add new entities and DAOs

• apache/shiro — The predecessor security framework this project explicitly replaces with custom AOP; understanding Shiro helps see why the author chose a simpler annotation-based approach
• PanJiaChen/vueAdmin-template — Vue frontend template that inspired this project's dynamic routing and permission-based menu rendering strategy
• lenve/vhr — Similar Chinese Spring Boot + Vue HR system with role-based permission control; shares RBAC philosophy and tech stack
• macrozheng/mall — Larger Spring Boot + Vue e-commerce reference with permission/role management; more production-hardened alternative with additional modules (payment, logistics)
• auth0/express-jwt — Reference implementation of token-based authentication pattern used in this backend's TokenService; helps understand stateless auth design

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for PermissionAspect.java and RequiresPermissions annotation logic

The repo implements a custom permission checking system via AOP (PermissionAspect.java) that replaces Shiro. Currently there are no visible unit tests for this critical permission validation logic. This is high-risk since permission checks are security-sensitive. Adding tests would verify the @RequiresPermissions annotation works correctly with Logical.AND/OR conditions, handles edge cases, and validates permission parsing.

• [ ] Create back/src/test/java/com/heeexy/example/config/filter/PermissionAspectTest.java
• [ ] Add test cases for @RequiresPermissions with single permission (e.g. 'article:add')
• [ ] Add test cases for multiple permissions with Logical.AND and Logical.OR
• [ ] Add test cases for unauthorized/authenticated exceptions from UnauthorizedException and UnauthenticatedException
• [ ] Mock RequestFilter and SessionUserInfo to provide test user context
• [ ] Verify exception handling in GlobalExceptionHandler for permission violations

Add comprehensive API documentation/Swagger integration to back/pom.xml and controllers

The backend implements button/interface-level permissions but has no API documentation. The three controllers (LoginController, UserController, ArticleController) would benefit from Swagger/SpringFox annotations to auto-generate OpenAPI docs. This helps new contributors understand the permission structure and required endpoints, especially since permission strings like 'article:add' are scattered throughout the codebase without clear documentation of what endpoints need what permissions.

• [ ] Add springfox-swagger2 and springfox-swagger-ui dependencies to back/pom.xml
• [ ] Create back/src/main/java/com/heeexy/example/config/SwaggerConfig.java
• [ ] Add @Api, @ApiOperation, @ApiParam annotations to LoginController.java, UserController.java, and ArticleController.java
• [ ] Document the permission strings required for each endpoint (e.g. 'article:add', 'user:edit')
• [ ] Add Swagger configuration to expose /swagger-ui.html endpoint
• [ ] Document the custom @RequiresPermissions annotation behavior in Swagger config

Add integration tests for token-based authentication flow in TokenService.java

Version 2.0.0 replaced session-based auth with token-based auth (TokenService.java), but there are no visible integration tests validating the end-to-end login->token generation->permission verification flow. This is critical for a permission management example repo. Tests should verify token creation, validation, expiration, and integration with RequestFilter.java and PermissionAspect.java.

• [ ] Create back/src/test/java/com/heeexy/example/service/TokenServiceIntegrationTest.java
• [ ] Add test for token generation during LoginController login flow
• [ ] Add test for token validation in RequestFilter.java extracting user permissions
• [ ] Add test for expired token rejection
• [ ] Add test for token-to-permission mapping used by @RequiresPermissions verification
• [ ] Test integration between TokenService, SessionUserInfo storage, and PermissionAspect permission checking

• Add unit tests for PermissionAspect.java that verify @RequiresPermissions blocks unpermitted requests and allows permitted ones; currently no test suite visible in file structure
• Create database migration scripts (Liquibase or Flyway) in back/src/main/resources/db/migration/ to document the required user/role/permission schema instead of manual SQL
• Document the token payload structure and JWT signing algorithm used in TokenService.java; add example curl commands to explain how to test endpoints with token headers in README

• High · Outdated Spring Boot Version with Known Vulnerabilities — back/pom.xml - parent version 2.3.10.RELEASE. The project uses Spring Boot 2.3.10.RELEASE, which is an older version (released in 2020) containing multiple known CVEs. This version is no longer receiving security updates and has been superseded by newer releases with critical security patches. Fix: Upgrade to Spring Boot 2.7.x or 3.x series. At minimum, update to the latest 2.3.x patch if 2.7+ is not compatible with the codebase. Review and test thoroughly for breaking changes.
• High · Incomplete Dependency Declaration - Truncated fastjson Dependency — back/pom.xml - fastjson dependency declaration. The pom.xml file contains an incomplete fastjson dependency declaration that is cut off mid-XML. This prevents proper dependency management and version pinning. Fastjson is known to have had deserialization vulnerabilities in older versions. Fix: Complete the fastjson dependency declaration with a specific version (use 1.2.83 or later which contains security fixes). Example: <version>1.2.83</version>. Ensure fastjson is necessary; consider using Jackson (Spring's default) instead.
• High · Token-Based Authentication Without Secure Token Generation Validation — back/src/main/java/com/heeexy/example/service/TokenService.java. The application uses token-based authentication (mentioned in v2.0.0 update) replacing session management. However, without visibility into TokenService implementation, there's risk of insecure token generation (weak randomness, predictable tokens, insufficient entropy) or missing token validation logic. Fix: Verify TokenService uses cryptographically secure random generation (java.security.SecureRandom). Implement token expiration, refresh token rotation, and secure storage. Use JWT with HS256 or RS256 if not already implemented. Add token signature validation on every request.
• Medium · Custom Permission Annotation Without Documented Validation Logic — back/src/main/java/com/heeexy/example/config/annotation/RequiresPermissions.java and back/src/main/java/com/heeexy/example/config/filter/PermissionAspect.java. The codebase uses custom @RequiresPermissions annotation and PermissionAspect for authorization checking. Without visibility into the implementation, there's potential for bypass vulnerabilities if the AOP aspect doesn't properly validate all entry points or has logic flaws. Fix: Ensure PermissionAspect: (1) validates ALL controller methods, (2) properly handles method inheritance, (3) implements default-deny policy, (4) logs authorization failures, (5) has comprehensive unit tests. Use AspectJ with proper pointcut configuration to prevent bypasses.
• Medium · RequestFilter Implementation Without Security Headers — back/src/main/java/com/heeexy/example/config/filter/RequestFilter.java. RequestFilter is present but without visibility into its implementation, critical security headers may be missing (X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Strict-Transport-Security, etc.). Fix: Implement comprehensive security headers in RequestFilter: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy, Strict-Transport-Security (HSTS), X-XSS-Protection. Use Spring Security's default header configuration if migrating from Shiro.
• Medium · SQL Injection Risk in MyBatis Mappers — back/src/main/resources/mapper/*.xml. The presence of XML mapper files (ArticleMapper.xml, LoginMapper.xml, UserMapper.xml) suggests MyBatis usage. Without visibility into the actual SQL, there's potential risk of SQL injection if dynamic SQL uses string concatenation instead of parameterized queries. Fix: Ensure all mapper XML files use parameterized queries with #{} placeholders instead of ${} string interpolation. Use MyBatis's built-in escaping mechanisms. Conduct code review of all dynamic SQL statements.
• Medium · Hardcoded Database Credentials in Configuration Files — undefined. Multiple environment-specific configuration files (application-local.yml, application-prod.yml) are present. These may contain database credentials. If committed to version control, Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.