这是一个典型的基于SQLAlchemy的RBAC权限系统数据模型实现,各模型分工明确,共同构成完整的权限管理系统。
实体关系:
用户(USER)和角色(ROLE)通过 USER_ROLE 中间表实现多对多关系
角色(ROLE)和权限(PERMISSION)通过 ROLE_PERMISSION 中间表实现多对多关系
关键连接点:
USER → USER_ROLE ← ROLE → ROLE_PERMISSION ← PERMISSION
这个链条完整表达了"用户→角色→权限"的授权路径
箭头含义:
||--o{
表示一对多关系
PK
表示主键
FK
表示外键
实际业务流:
当检查用户是否有某接口的访问权限时,系统会:
用户ID → 查询USER_ROLE → 获取角色列表 →
查询ROLE_PERMISSION → 获取权限列表 →
匹配权限中的resource字段与当前请求接口
这个图示清晰地展示了您提供的四个模型如何协作完成RBAC权限控制。如果需要更详细的流程图或时序图,我可以进一步补充。
核心作用:定义系统中的角色实体
关键字段:
role_name
: 角色唯一标识(如admin/hr/interviewer)
description
: 角色描述信息
关联关系:
users
: 通过UserRole关联到用户(一对多)
permissions
: 通过RolePermission关联到权限(一对多)
业务意义:角色是权限分配的中间层,用户通过角色间接获得权限
核心作用:定义系统中的具体权限项
关键字段:
permission_name
: 权限唯一标识(如knowledge_create)
resource
: 关联的资源路径/API端点
关联关系:
roles
: 通过RolePermission关联到角色(一对多)
业务意义:权限是系统中最细粒度的访问控制单元,直接对应具体操作
核心作用:维护用户与角色的多对多关系
关键设计:
联合唯一约束(uq_user_role
): 防止重复分配相同角色
级联删除: 用户删除时自动解除关联
关联关系:
user
: 关联到用户表
role
: 关联到角色表
业务意义:实现"用户拥有哪些角色"的映射关系
核心作用:维护角色与权限的多对多关系
关键设计:
联合唯一约束(uq_role_permission
): 防止重复分配相同权限
级联删除: 角色删除时自动解除关联
关联关系:
role
: 关联到角色表
permission
: 关联到权限表
业务意义:实现"角色包含哪些权限"的映射关系
管理员创建权限(Permission)并定义其对应的资源
创建角色(Role)并将相关权限关联到角色(RolePermission)
为用户分配角色(UserRole)
系统通过检查用户的角色→权限→资源路径链来确定访问权限
这种设计实现了权限管理的解耦,使系统能够灵活应对权限变更,同时通过中间表实现了多对多关系的维护。
class User(Base):
__tablename__ = 'user'
__table_args__ = {'extend_existing': True}
user_id = Column(Integer, primary_key=True, autoincrement=True, comment='Primary Key')
user_name = Column(String(100), nullable=False)
password = Column(String(200), nullable=False)
user_email = Column(String(100), nullable=False, unique=True)
user_department = Column(String(100), nullable=True)
join_time = Column(DateTime, nullable=False, default=datetime.now)
# 关联 Session 模型,代表该用户的所有会话
sessions = relationship("Session", back_populates="user", cascade="all, delete-orphan")
# 关联 Knowledge 模型,代表该用户关联的所有知识
knowledge = relationship("Knowledge", back_populates="user", cascade="all, delete-orphan")
# 添加与UserRole的关系
roles = relationship("UserRole", back_populates="user", cascade="all, delete-orphan")
class Role(Base):
__tablename__ = 'role'
__table_args__ = {'extend_existing': True}
role_id = Column(Integer, primary_key=True, autoincrement=True, comment='Primary Key')
role_name = Column(String(50), nullable=False, unique=True, comment='角色名称,如admin/hr/interviewer')
description = Column(String(200), comment='角色描述')
create_time = Column(DateTime, nullable=False, default=datetime.now)
modify_time = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)
# 关联到UserRole和RolePermission
users = relationship("UserRole", back_populates="role", cascade="all, delete-orphan")
permissions = relationship("RolePermission", back_populates="role", cascade="all, delete-orphan")
class Permission(Base):
__tablename__ = 'permission'
__table_args__ = {'extend_existing': True}
permission_id = Column(Integer, primary_key=True, autoincrement=True, comment='Primary Key')
permission_name = Column(String(100), nullable=False, unique=True, comment='权限名称,如knowledge_create/session_delete')
description = Column(String(200), comment='权限描述')
resource = Column(String(200), comment='对应的资源路径/API端点')
create_time = Column(DateTime, nullable=False, default=datetime.now)
modify_time = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)
# 关联到RolePermission
roles = relationship("RolePermission", back_populates="permission", cascade="all, delete-orphan")
class UserRole(Base):
__tablename__ = 'user_role'
__table_args__ = (
UniqueConstraint('user_id', 'role_id', name='uq_user_role'),
{'extend_existing': True}
)
id = Column(Integer, primary_key=True, autoincrement=True)
user_id = Column(Integer, ForeignKey('user.user_id', ondelete='CASCADE'), nullable=False)
role_id = Column(Integer, ForeignKey('role.role_id', ondelete='CASCADE'), nullable=False)
create_time = Column(DateTime, nullable=False, default=datetime.now)
# 关联到User和Role
user = relationship("User", back_populates="roles")
role = relationship("Role", back_populates="users")
class RolePermission(Base):
__tablename__ = 'role_permission'
__table_args__ = (
UniqueConstraint('role_id', 'permission_id', name='uq_role_permission'),
{'extend_existing': True}
)
id = Column(Integer, primary_key=True, autoincrement=True)
role_id = Column(Integer, ForeignKey('role.role_id', ondelete='CASCADE'), nullable=False)
permission_id = Column(Integer, ForeignKey('permission.permission_id', ondelete='CASCADE'), nullable=False)
create_time = Column(DateTime, nullable=False, default=datetime.now)
# 关联到Role和Permission
role = relationship("Role", back_populates="permissions")
permission = relationship("Permission", back_populates="roles")
一种紧凑的、URL安全的令牌格式
包含三部分:Header(头部)、Payload(负载)和Signature(签名)
用于在各方之间安全地传输信息
一个授权框架,允许第三方应用获取对资源的有限访问权限
定义了四种授权流程(授权码、隐式、密码、客户端凭证)
用户发起授权请求
客户端将用户重定向到授权服务器
携带参数:response_type=code
, client_id
, redirect_uri
, scope
等
用户认证与同意
用户在授权服务器登录并同意请求的权限
获取授权码
授权服务器返回授权码到客户端的redirect_uri
用授权码交换令牌
客户端向授权服务器的令牌端点发送请求
携带:grant_type=authorization_code
, code
, redirect_uri
, client_id
, client_secret
返回JWT令牌
授权服务器验证后返回访问令牌(通常是JWT)和刷新令牌
响应示例:
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "def50200ae2f..."
}
使用访问令牌访问资源
客户端在请求头中加入:Authorization: Bearer
资源服务器验证JWT签名和声明
刷新令牌(可选)
当访问令牌过期时,使用刷新令牌获取新的访问令牌
自包含:JWT包含所有必要信息,减少数据库查询
可验证性:资源服务器可以独立验证JWT而不需联系授权服务器
标准化结构:易于跨语言和平台实现
# app/middlewares/permission.py
from fastapi import Request, HTTPException, Depends
from sqlalchemy.orm import Session
from app.db_init import SessionLocal
from app.models.model import User, Permission, RolePermission, UserRole, Role # 添加 Role 导入
from functools import wraps
def permission_required(permission_name: str):
"""
权限检查依赖工厂函数
"""
async def dependency(request: Request):
db: Session = SessionLocal()
try:
user_id = getattr(request.state, 'user_id', None)
if not user_id:
raise HTTPException(status_code=401, detail="未认证")
# 检查是否是管理员/root用户
user = db.query(User).filter(User.user_id == user_id).first()
if not user:
raise HTTPException(status_code=401, detail="用户不存在")
# 检查用户角色
admin_role = (
db.query(UserRole)
.join(Role, Role.role_id == UserRole.role_id)
.filter(UserRole.user_id == user_id)
.filter(Role.role_name == 'admin')
.first()
)
if admin_role:
return # 管理员直接通过权限检查
# 普通用户权限检查
has_permission = db.query(Permission).join(
RolePermission,
RolePermission.permission_id == Permission.permission_id
).join(
UserRole,
UserRole.role_id == RolePermission.role_id
).filter(
UserRole.user_id == user_id,
Permission.permission_name == permission_name
).first()
if not has_permission:
raise HTTPException(status_code=403, detail="权限不足")
finally:
db.close()
return Depends(dependency)
permission_required
函数是一个 FastAPI 的权限检查依赖工厂函数,主要用于实现基于权限的访问控制。它的主要作用和功能如下:
功能概述:
它是一个装饰器工厂函数,接收一个权限名称作为参数,返回一个 FastAPI 依赖项
用于检查当前请求的用户是否拥有指定的权限
工作流程:
从请求中获取用户 ID
查询数据库验证用户是否存在
检查用户是否是管理员角色(role_name 为 'admin'),如果是则直接通过检查
对于非管理员用户,检查用户是否拥有指定的权限
如果没有权限则返回 403 错误
权限检查逻辑:
通过连接查询检查用户角色关联的权限
查询涉及多个表:User → UserRole → RolePermission → Permission
只有当用户至少有一个角色拥有指定的权限时才会通过检查
异常处理:
未认证用户(无 user_id):返回 401
用户不存在:返回 401
权限不足:返回 403
在 Web 开发中,中间件(Middleware) 是一种机制,用于在 HTTP 请求到达路由处理函数之前 或 响应返回客户端之前 执行某些逻辑。它类似于一个“拦截器”,可以对请求和响应进行预处理或后处理。
全局处理请求/响应
例如:身份验证、日志记录、跨域处理(CORS)、请求限流、数据压缩等。
修改请求或响应
例如:添加请求头、解析请求体、修改响应数据。
拦截非法请求
例如:检查权限(如你的 permission_required
)、阻止未授权的访问。
在 FastAPI 或类似的框架(如 Express.js、Django)中,中间件通常按照 洋葱模型(Onion Model) 工作:
请求 → 中间件1 → 中间件2 → ... → 路由处理 → ... → 中间件2 → 中间件1 → 响应
请求阶段:中间件按顺序执行(如先验证身份,再检查权限)。
响应阶段:中间件按相反顺序执行(如先记录日志,再返回数据)。
from fastapi import FastAPI, Request
app = FastAPI()
@app.middleware("http")
async def log_requests(request: Request, call_next):
print(f"收到请求: {request.method} {request.url}")
response = await call_next(request) # 继续执行后续中间件或路由
print(f"返回响应: {response.status_code}")
return response
这个中间件会在 每个请求前后 打印日志。
permission_required
)from fastapi import Depends, HTTPException
def check_auth(token: str):
if token != "secret":
raise HTTPException(status_code=403, detail="无权访问")
return True
@app.get("/admin")
async def admin_route(auth: bool = Depends(check_auth)):
return {"message": "欢迎管理员"}
Depends(check_auth)
是一个依赖项,作用类似于中间件,但更灵活(可以针对单个路由使用)。
特性 | 中间件 | 依赖注入(如 Depends ) |
---|---|---|
作用范围 | 全局或路由组 | 单个路由 |
执行顺序 | 所有请求必经 | 仅对声明了的路由生效 |
典型用途 | 日志、CORS、全局认证 | 细粒度权限检查、数据库会话管理 |
permission_required
是中间件吗?严格来说,它 不是传统中间件,而是一个 依赖项工厂函数(返回 Depends
)。但它实现了类似中间件的功能(权限检查),只是作用范围更精确(仅对使用它的路由生效)。
中间件:适合全局逻辑(如日志、CORS)。
依赖注入:适合路由级逻辑(如权限、数据库会话)。
你的 permission_required
是依赖注入的典型应用,用于实现 RBAC(基于角色的访问控制)。
@router.post('/login')
async def login(request_data: LoginRequest, db = Depends(get_db)):
'''
登录界面
'''
username = request_data.username
password = request_data.password
# 根据用户名查询数据库中用户的密码
info = AuthService.select_user_info(username, db)
if info is None:
return {
'code': 401,
'message': 'user not found'
}
# 密码验证
if password != info['password']:
return {
'code': 401,
'message': 'password error'
}
# 获取用户角色
user_roles = AuthService.get_user_roles(info['user_id'], db)
is_admin = 'admin' in [role.lower() for role in user_roles]
# 获取用户权限
permissions = AuthService.get_user_permissions(info['user_id'], db)
if permissions is None:
permissions = []
# 创建JWT令牌
access_token_expires = timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
access_token = create_access_token(
data={
"sub": str(info['user_id']), # 确保user_id是字符串
"username": info['user_name'],
"permissions": permissions,
"is_admin": is_admin,
"roles": user_roles
},
expires_delta=access_token_expires
)
return {
'code': 200,
'message': 'success',
'data': {
'user_id': info['user_id'],
'username': info['user_name'],
'access_token': access_token,
'token_type': 'bearer',
'permissions': permissions,
'roles': user_roles,
'is_admin': is_admin
}
}
这个 login
函数是一个 FastAPI 路由处理函数,用于实现用户登录认证流程。它的核心作用是:
用户身份认证
接收前端提交的用户名和密码(通过 LoginRequest
模型)。
验证用户名是否存在、密码是否正确。
返回 401 错误码和提示信息(如 "user not found" 或 "password error")。
权限和角色信息收集
查询用户的角色(如 user_roles
)并检查是否是管理员(is_admin
)。
查询用户拥有的权限列表(permissions
)。
生成 JWT 令牌
使用 create_access_token
生成包含用户信息的 JWT(有效期通过 ACCESS_TOKEN_EXPIRE_MINUTES
控制)。
令牌中存储的关键数据:
{
"sub": "用户ID", # 用户唯一标识
"username": "用户名",
"permissions": ["权限1", "权限2"], # 用户权限列表
"is_admin": True/False, # 是否是管理员
"roles": ["角色1", "角色2"] # 用户角色列表
}
返回登录结果
返回 200 状态码和用户信息(包括令牌、权限、角色等),供前端后续使用。
参数接收
通过 LoginRequest
模型(未展示但应包含 username
和 password
字段)接收前端提交的登录数据。
用户验证
调用 AuthService.select_user_info
查询数据库,检查用户名是否存在。
比对数据库中的密码(明文比对,实际项目中应使用 哈希密码比对,如 bcrypt
)。
权限角色查询
通过 AuthService.get_user_roles
获取用户角色列表,并检查是否包含 admin
角色。
通过 AuthService.get_user_permissions
获取用户权限列表(用于前端动态路由或按钮权限控制)。
令牌生成
使用 create_access_token
(可能是 fastapi-jwt
或类似库)生成 JWT,包含用户关键信息。
响应返回
返回结构化响应,包含令牌和用户信息,例如:
{
"code": 200,
"message": "success",
"data": {
"user_id": 123,
"username": "john",
"access_token": "xxx.yyy.zzz",
"permissions": ["read", "write"],
"roles": ["user"],
"is_admin": false
}
}
安全注意事项
密码明文存储问题:当前代码直接比对明文密码,实际项目应使用 密码哈希(如 bcrypt
)存储和验证。
JWT 敏感信息:令牌中存储了 permissions
和 roles
,需确保 JWT 使用 HTTPS 传输并设置合理有效期。
权限控制设计
前端可根据返回的 permissions
和 roles
动态渲染界面。
后端可通过 permission_required
中间件(如你之前提供的)进一步校验权限。
扩展性
可添加登录日志记录、多设备登录限制、验证码等功能。
前端提交登录表单 → 后端验证 → 返回令牌。
前端将令牌存储在 localStorage
或 Cookie
中,后续请求通过 Authorization: Bearer
头部携带。
其他受保护的路由通过中间件校验令牌和权限(如 @router.get("/admin", dependencies=[Depends(permission_required("admin_access"))]
)。
这个函数是典型的认证系统核心部分,实现了从登录到权限令牌分发的完整流程。
from fastapi import Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
from jose import JWTError, jwt
from datetime import datetime, timedelta
from utils.configs import SECRET_KEY, ALGORITHM, ACCESS_TOKEN_EXPIRE_MINUTES
from fastapi import Request
# OAuth2 配置
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")
# 创建访问令牌
def create_access_token(data: dict, expires_delta: timedelta = None):
to_encode = data.copy()
if expires_delta:
expire = datetime.utcnow() + expires_delta
else:
expire = datetime.utcnow() + timedelta(minutes=15)
to_encode.update({"exp": expire})
encoded_jwt = jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
return encoded_jwt
async def get_current_user(token: str = Depends(oauth2_scheme)):
credentials_exception = HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Could not validate credentials",
headers={"WWW-Authenticate": "Bearer"},
)
try:
payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
user_id = payload.get("sub")
if user_id is None:
raise credentials_exception
permissions = payload.get("permissions", [])
username = payload.get("username")
is_admin = payload.get("is_admin", False)
roles = payload.get("roles", [])
# 返回一个包含所需信息的字典
return {
"user_id": user_id,
"username": username,
"permissions": permissions,
"is_admin": is_admin,
"roles": roles
}
except JWTError:
raise credentials_exception
async def auth_middleware(request: Request, call_next):
try:
token = request.headers.get('Authorization')
if token and token.startswith('Bearer '):
token = token.split(' ')[1]
payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
request.state.user_id = payload.get("sub")
request.state.permissions = payload.get("permissions", [])
except JWTError:
pass
response = await call_next(request)
return response
这几个函数共同构成了一个 FastAPI 的 JWT 认证系统,分别负责 令牌生成、用户认证和请求拦截。以下是它们的详细作用:
create_access_token
- JWT 令牌生成作用:
生成一个包含用户信息的 JWT(JSON Web Token),用于身份验证和授权。
关键逻辑:
接收一个字典 data
(包含用户信息如 user_id
、permissions
等)。
设置令牌过期时间(默认 15 分钟,或通过 expires_delta
自定义)。
使用 SECRET_KEY
和 ALGORITHM
(如 HS256)签名令牌。
示例输出:
token = create_access_token({"sub": "123", "username": "john"})
# 类似:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE2...
get_current_user
- 当前用户认证作用:
解析请求中的 JWT 令牌,验证用户身份并返回用户信息。
关键逻辑:
通过 OAuth2PasswordBearer
自动从请求头 Authorization: Bearer
提取令牌。
解码令牌并验证签名(使用 SECRET_KEY
)。
提取关键字段(如 user_id
、permissions
、is_admin
)。
如果令牌无效或过期,抛出 401 Unauthorized
错误。
典型用法:
@app.get("/protected")
async def protected_route(user: dict = Depends(get_current_user)):
return {"user": user}
auth_middleware
- 认证中间件作用:
拦截所有请求,解析 JWT 令牌并将用户信息注入到 request.state
中,供后续路由或中间件使用。
关键逻辑:
从请求头提取 Bearer
令牌。
解码令牌并提取 user_id
和 permissions
,存入 request.state
。
如果令牌无效,静默跳过(不中断请求,适合非强制校验的场景)。
与 get_current_user
的区别:
特性 | auth_middleware |
get_current_user |
---|---|---|
作用范围 | 全局(所有请求) | 单个路由(需显式声明 Depends ) |
认证严格性 | 静默失败(仅注入数据) | 严格失败(401 错误) |
典型用途 | 日志、基础用户信息注入 | 需要强认证的路由 |
用户登录
调用 create_access_token
生成令牌并返回给前端。
前端请求
在请求头中添加 Authorization: Bearer
。
请求处理
auth_middleware
拦截请求,解析令牌并注入用户信息到 request.state
。
路由层可通过 get_current_user
进一步严格校验(如需要权限的接口)。
密钥管理
SECRET_KEY
必须保密,且不要硬编码在代码中(从环境变量读取)。
令牌有效期
生产环境中 ACCESS_TOKEN_EXPIRE_MINUTES
不宜过长(通常 15-60 分钟)。
算法选择
推荐使用 HS256
(对称加密)或 RS256
(非对称加密)。
中间件静默失败
auth_middleware
不强制拦截无效令牌,需确保关键路由额外依赖 get_current_user
。
刷新令牌:添加 refresh_token
机制实现无感续期。
权限校验:结合 permission_required
(你之前的代码)实现细粒度控制。
日志记录:在中间件中记录用户操作日志。
这些函数共同构建了一个完整的 JWT 认证体系,覆盖了从令牌生成到请求处理的完整链路。
然后将这个认证中间件添加到接收HTTP请求之前
然后在路由中添加权限名称
在 FastAPI 中,_=permission_required("abilities_read")
是一种 依赖注入(Dependency Injection) 的用法,用于在路由处理函数执行前进行 权限校验。以下是详细解释:
permission_required("abilities_read")
这是一个依赖项工厂函数(你之前定义的),它会检查当前用户是否拥有 abilities_read
权限。
_=
将依赖项的返回值赋值给变量 _
(下划线是 Python 中约定用于“忽略此变量”的命名方式),表示我们不需要在函数体内使用这个返回值。
请求到达路由
当客户端访问 GET /api/abilities
时,FastAPI 会先执行 permission_required("abilities_read")
的校验逻辑。
权限校验
如果用户 有权限:继续执行 get_abilities
函数体。
如果用户 无权限:直接返回 403 Forbidden
错误(由 permission_required
抛出)。
处理业务逻辑
只有通过权限校验后,才会调用 get_all_competency_items()
获取数据并返回。
_=
?明确忽略返回值:
permission_required
可能返回某些值(如用户信息),但当前路由不需要使用它,用 _
表示“故意忽略”。
代码可读性:
明确告诉其他开发者:“这里有一个权限检查,但我不需要它的结果”。
import axios from 'axios'
import { API_URLS } from '@/config/api'
const state = {
token: localStorage.getItem('token') || null,
user: null,
permissions: [],
role: null
}
const mutations = {
SET_TOKEN(state, token) {
state.token = token
localStorage.setItem('token', token)
axios.defaults.headers.common['Authorization'] = `Bearer ${token}`
},
CLEAR_TOKEN(state) {
state.token = null
localStorage.removeItem('token')
delete axios.defaults.headers.common['Authorization']
},
SET_USER(state, user) {
state.user = user
},
SET_PERMISSIONS(state, permissions) {
state.permissions = permissions
},
SET_ROLE(state, role) {
state.role = role
}
}
const actions = {
async login({ commit }, { username, password }) {
const response = await axios.post(API_URLS.LOGIN, { username, password })
commit('SET_TOKEN', response.data.access_token)
commit('SET_PERMISSIONS', response.data.permissions)
return response.data
},
async fetchPermissions({ commit, state }) {
if (!state.token) return
const response = await axios.get(API_URLS.PERMISSIONS)
commit('SET_PERMISSIONS', response.data.permissions)
return response.data
},
logout({ commit }) {
commit('CLEAR_TOKEN')
commit('SET_USER', null)
commit('SET_PERMISSIONS', [])
commit('SET_ROLE', null)
},
async getPermissions({ commit }) {
const response = await axios.get('/auth/permissions')
commit('SET_PERMISSIONS', response.data)
return response.data
}
}
export default {
namespaced: true,
state,
mutations,
actions
}
import { createStore } from 'vuex'
import user from './modules/user' // 导入user模块
export default createStore({
state: {
userId: '',
isAuthenticated: false
},
mutations: {
setUserId(state, id) {
state.userId = parseInt(id)
state.isAuthenticated = !!id
}
},
modules: {
user // 注册user模块
},
// 添加持久化
plugins: [
store => {
// 初始化时从 localStorage 获取状态
const userId = localStorage.getItem('userId')
if (userId) {
store.commit('setUserId', userId)
}
// 订阅 mutation
store.subscribe((mutation, state) => {
if (mutation.type === 'setUserId') {
localStorage.setItem('userId', state.userId)
}
})
}
]
})
这两部分代码共同构成了一个 基于 Vuex 的前端状态管理 + JWT 认证体系,主要处理用户认证、权限管理和状态持久化。以下是详细解析:
user
模块(核心功能)const state = {
token: localStorage.getItem('token') || null, // 从本地存储初始化Token
user: null, // 用户信息
permissions: [], // 权限列表
role: null // 用户角色
}
方法/属性 | 功能说明 |
---|---|
mutations.SET_TOKEN |
存储Token到Vuex和localStorage,并设置Axios全局请求头(Authorization ) |
mutations.CLEAR_TOKEN |
退出登录时清除Token和Axios请求头 |
actions.login |
提交登录请求,保存Token和权限到Vuex |
actions.logout |
清理所有用户状态(Token、用户信息、权限等) |
actions.fetchPermissions |
主动获取用户权限(需Token有效) |
用户登录
权限控制
前端根据 state.permissions
动态渲染菜单/按钮。
每次API请求自动携带JWT(通过Axios拦截器)。
index.js
(Vuex主仓库)export default createStore({
state: {
userId: '', // 全局用户ID
isAuthenticated: false // 认证状态
},
modules: {
user // 注册user模块(嵌套状态)
},
plugins: [ /* 持久化逻辑 */ ]
})
模块化
将用户相关状态(user
模块)与全局状态分离,避免命名冲突。
通过 namespaced: true
启用模块命名空间。
状态持久化
初始化时:从 localStorage
读取 userId
恢复登录状态。
状态变化时:通过 store.subscribe
监听 setUserId
突变,自动同步到 localStorage
。
认证状态同步
isAuthenticated
由 userId
自动计算得出(!!id
转为布尔值)。