最近来问毕设选题的同学特别多十个里有七八个都在犹豫做什么才能既好写又能顺利答辩。我个人的建议非常明确如果你不想被简单管理系统卷死又没精力挑战算法难度那用 Python 做一个统一身份认证服务绝对是性价比很高的选择。它听起来抽象拆开看就是一套让多个系统共用同一份账号密码的登录鉴权中心。这篇就完整聊聊我做完这个项目的思路、代码、踩坑以及如何把它和 JAVA、PHP、小程序、爬虫、数据可视化这些方向串起来作为计算机毕设的完整作品。标题里提到的白嫖源码 演示录像是真的我把自己做完的这套工程整理成了一份可直接运行的毕设资源包里面包含全部源码、数据库脚本、部署说明和演示视频。项目本身不复杂但把认证、鉴权、多端接入、日志可视化这些点全打通之后你会发现它远比XX管理系统这种传统毕设有讲头。下面我把整个项目的设计逻辑和实操过程拆开一步步说清楚。1. 为什么我推荐把统一身份认证作为毕设主项目1.1 它到底解决的是什么问题很多同学一开始不清楚统一身份认证的价值我先用大白话解释一下。假设你同时做了三样东西一个后台管理网站、一个微信小程序商城、一个爬虫采集脚本。按照常见的做法每个系统各自建一张用户表各搞一套注册登录。用户要在三个地方记三套账号密码你自己也要维护三份用户数据改密码得改三处。统一身份认证服务做的事情就是把账号密码这一套东西全部收拢到一个独立服务里。其他系统不再自己注册登录而是通过接口把登录请求转给认证服务。认证服务确认用户身份后签发一个 Token各系统拿着这个 Token 请求受保护的接口。这样一来用户只需要记一个账号所有接入的系统都能用你在任何一处修改密码其他系统立刻生效。这就像写字楼的统一门禁你不需要在每个办公室门口各配一把钥匙只要前台发一张工牌所有能刷的门都能进。毕设答辩时把这个类比讲给老师听对方很快就能 get 到你做的到底是什么。1.2 答辩时的含金量体现在哪里老师评判毕设很看重题目本身有没有技术纵深。写一个图书管理系统讲的内容无非是增删改查翻来覆去没有可扩展的点。但统一身份认证服务这个题目天然带有几个高频考点Token 的生成、解析、过期和刷新机制密码的哈希存储与防暴力破解策略基于角色的访问控制RBAC模型多端接入时的跨域与请求头设计认证日志的采集与可视化展示。每一个拿出来都能单独扩展成一节答辩问题而且都有学术界和工业界的成熟方案可以引用。老师一听就知道你不是在纯堆 CRUD而是接触到了真实后端项目里最核心的模块。1.3 它适配哪些毕设方向我做过一个汇总表格方便你判断自己的方向能不能挂靠这套服务方向在毕设中的角色如何与统一认证结合JAVA / PHP业务系统子端接入认证服务作为受保护的前后端项目微信小程序移动端入口通过 wx.login 换取本地 Token叫醒小程序去访问认证服务爬虫数据采集工具使用认证服务签发的 Token 调用数据接口校验脚本身份APP含 Android/iOS移动客户端登录时调用认证接口存储 Token后续请求携带数据可视化认证日志大屏通过 ECharts 等绘制登录趋势、用户活跃、来源地域分布C# / C 桌面程序桌面客户端用 HTTP 请求接入认证服务完成本地登录状态绑定所以你看自己用什么语言写子系统不关键认证服务能作为公共底座把它们全部串联起来整体作品的故事就完整了。2. 项目功能拆解一台认证服务管住所有系统2.1 最小闭环长什么样做毕设不用一上来就实现 OAuth2、单点登录协议、双因素认证这些东西先跑通一个最小闭环后面再逐步加功能。我建议的最小功能集是注册用户提交用户名和密码服务端校验并存储登录校验用户名密码签发 Access Token 和 Refresh Token校验受保护接口解析请求头里的 Token判断是否有效刷新Access Token 过期后用 Refresh Token 换新的登出将 Token 加入黑名单或删除刷新 Token使其失效用户信息通过 Token 获取当前登录用户的资料。功能列表比想象中短但每一个都可以讲出很多细节。我当时的做法是先把这 6 个接口跑通再补充分页、密码修改、角色分配和日志记录工作量安排非常合理。2.2 多端接入的界面形态为了让老师觉得系统真实可用建议至少做两个端一个 PC 网页管理端一个微信小程序端。网页端用来演示后端管理员功能小程序端用来演示 C 端用户登录。爬虫脚本和数据可视化可以作为补充展示。演示的时候先打开 PC 端的登录页输入刚才注册的账号密码同一个账号再在小程序里登录也能成功而且两边看到的个人信息完全一致这就直观体现了统一的含义。图表数据可以由认证服务记录的日志实时生成展示最近一小时内登录成功的次数和失败次数。2.3 演示录像怎么编排更抓人标题里强调演示录像我建议录像不要从头到尾录操作那样冗长且没有重点。我给你一个可以照抄的脚本痛点引入一句话说传统多系统登录账号不统一的问题启动服务命令行展示认证服务启动数据库连接成功注册账号录注册过程故意输入一次错误密码展示校验逻辑登录成功PC 端登录F12 打开开发者工具展示请求头里的 Token多端同步切换到小程序模拟器用同样的账号登录展示两者信息一致访问受保护接口用 Postman 模拟爬虫脚本调用接口不带 Token 返回 401带 Token 返回数据数据可视化打开日志大屏展示刚才产生的登录记录。这一套录下来大概十分钟节奏紧凑信息量大老师看完就会觉得项目完整度非常高。3. 技术选型与数据库模型不堆技术把基础打结实3.1 Flask 还是 Django很多同学纠结用 Flask 还是 Django我的选择是 Flask。理由是 Flask 足够轻路由和视图函数直观Token 的签发和校验完全由自己控制方便在答辩时把原理说清楚。Django 虽然内置了用户认证系统和 Admin 后台但它把太多细节封装掉了你很难在答辩时解释Token 到底在里面是怎么流转的。如果学校要求必须用企业级框架Django 也完全可以跑只是需要在配置里替换默认的 session 认证方案改成自定义的 JWT 中间件。两者对比大致如下对比项Flask JWTDjango 自定义认证上手速度快核心逻辑全透明较快但嵌套封装多默认功能少自己补多自带 Admin答辩讲述容易讲清 Token 原理容易扯到 Django 内部机制适合场景演示为主加分项很多的项目我自己最终选了 Flask SQLAlchemy PyJWT代码量不大架构足够清晰。3.2 数据库表设计数据库我设计成五张核心表用户表users、角色表roles、权限表permissions、用户角色关联表user_roles、角色权限关联表role_permissions。另外加了两张辅助表客户端应用表applications和认证日志表auth_logs。用户表主要字段如下CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username VARCHAR(64) UNIQUE NOT NULL, password_hash VARCHAR(128) NOT NULL, email VARCHAR(120), is_active BOOLEAN DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );password_hash 存的是哈希后的密码绝不存明文。auth_logs 表用来记录每次登录/登出的 IP、时间、结果、操作类型后面可视化就用它当数据源。3.3 密码加密方案千万不要用 MD5 或者明文存密码这是毕设答辩里最容易被老师一眼看穿的扣分点。我用的是 Werkzeug 自带的generate_password_hash默认算法是 pbkdf2:sha256内部自动加盐。这样做的好处是每次哈希结果都带随机盐同样密码两次哈希结果不一样校验时调用check_password_hash自动把盐提取出来重新计算攻击者即使拿到数据库也无法反推明文。如果你出于学习目的想自己实现至少也要用hashlib.pbkdf2_hmac做几千次迭代加盐不要把简单sha256(password)这种东西写进项目。4. 核心代码实现从注册登录到单点登录的完整链路4.1 注册接口与密码哈希注册接口的核心逻辑非常简单接收用户名、密码判断用户名是否已存在然后用哈希函数处理密码存入数据库。示例代码如下from werkzeug.security import generate_password_hash from flask import request, jsonify from models import User, db app.route(/api/auth/register, methods[POST]) def register(): data request.get_json() username data.get(username) password data.get(password) if not username or not password: return jsonify({code: 400, msg: 用户名和密码不能为空}), 400 if User.query.filter_by(usernameusername).first(): return jsonify({code: 400, msg: 用户名已存在}), 400 user User( usernameusername, password_hashgenerate_password_hash(password) ) db.session.add(user) db.session.commit() return jsonify({code: 201, msg: 注册成功}), 201我建议在注册接口里加上用户名长度检查、密码必须包含字母和数字等校验逻辑因为老师在答辩时经常先看接口健壮性而不是先看前端界面。4.2 登录接口与 JWT 签发登录接口执行两件事验证凭证签发 Token。JWT 我用 PyJWT 库生成PayLoad 里放用户 ID、用户名、角色信息设置过期时间。关键代码如下import jwt import datetime from werkzeug.security import check_password_hash SECRET_KEY your_secret_key ACCESS_TOKEN_EXPIRES_HOURS 1 REFRESH_TOKEN_EXPIRES_DAYS 7 app.route(/api/auth/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) user User.query.filter_by(usernameusername).first() if not user or not check_password_hash(user.password_hash, password): return jsonify({code: 401, msg: 用户名或密码错误}), 401 if not user.is_active: return jsonify({code: 403, msg: 账号已被禁用}), 403 access_payload { sub: user.id, username: user.username, type: access, exp: datetime.datetime.utcnow() datetime.timedelta(hoursACCESS_TOKEN_EXPIRES_HOURS), iat: datetime.datetime.utcnow() } refresh_payload { sub: user.id, type: refresh, exp: datetime.datetime.utcnow() datetime.timedelta(daysREFRESH_TOKEN_EXPIRES_DAYS), iat: datetime.datetime.utcnow() } access_token jwt.encode(access_payload, SECRET_KEY, algorithmHS256) refresh_token jwt.encode(refresh_payload, SECRET_KEY, algorithmHS256) return jsonify({ code: 200, msg: 登录成功, access_token: access_token, refresh_token: refresh_token, user: {id: user.id, username: user.username} }), 200这里的小细节是把iat设置为签发时间exp设置为过期时间。后面校验时 PyJWT 会自动校验exp一旦过期会抛出ExpiredSignatureError。4.3 鉴权装饰器与接口保护受保护接口的鉴权逻辑可以封装成一个装饰器这样每个视图只需要在上面加一行require_auth即可。装饰器解析请求头里Authorization: Bearer token解码后把用户信息挂到request.current_user上。from functools import wraps from flask import request, jsonify import jwt def require_auth(f): wraps(f) def decorated(*args, **kwargs): auth_header request.headers.get(Authorization) if not auth_header or not auth_header.startswith(Bearer ): return jsonify({code: 401, msg: 缺少访问令牌}), 401 token auth_header.split( )[1] try: payload jwt.decode(token, SECRET_KEY, algorithms[HS256]) if payload.get(type) ! access: return jsonify({code: 401, msg: 令牌类型错误}), 401 request.current_user { id: payload.get(sub), username: payload.get(username) } except jwt.ExpiredSignatureError: return jsonify({code: 401, msg: 令牌已过期}), 401 except jwt.InvalidTokenError: return jsonify({code: 401, msg: 无效令牌}), 401 return f(*args, **kwargs) return decorated在做接口保护演示时先不带 Token 请求返回 401再带 Token 请求返回正常数据。这一步非常直观建议录像时专门录一小段。4.4 单点登录的实操方案真正的企业级单点登录SSO涉及 CAS、OAuth2、OIDC 等协议比较复杂。毕设阶段只需要实现多个应用共用一个认证中心的精简版即可。我的实现思路是这样的所有接入系统把 Token 存放在各自的前端存储中网页是 localStorage小程序是 wx.storage每个受保护接口都统一调用认证服务的/api/auth/introspect接口或本地验证 JWT 签名只要所有系统的 JWT 使用同一个 SECRET_KEY 签发和验证任意一个系统签发的 Token其他系统都能识别。这样同一账号在多系统间保持登录的效果就实现了。更简单的方式是在同一个域名下部署多个前端子应用这样 localStorage 本来就是共享的。如果要做跨域名可以用 iframe postMessage 实现 Token 中转但那里坑比较多我建议毕设别做那么深除非老师明确要求。4.5 刷新 Token 与自动登录Access Token 设置 1 小时过期Refresh Token 设置 7 天过期。前端发请求时如果收到 401再用 Refresh Token 调用刷新接口换新 Token。代码如下app.route(/api/auth/refresh, methods[POST]) def refresh(): data request.get_json() refresh_token data.get(refresh_token) if not refresh_token: return jsonify({code: 400, msg: 缺少刷新令牌}), 400 try: payload jwt.decode(refresh_token, SECRET_KEY, algorithms[HS256]) if payload.get(type) ! refresh: return jsonify({code: 401, msg: 刷新令牌类型错误}), 401 except jwt.InvalidTokenError: return jsonify({code: 401, msg: 刷新令牌无效}), 401 user User.query.get(payload.get(sub)) if not user: return jsonify({code: 401, msg: 用户不存在}), 401 new_access_payload { sub: user.id, username: user.username, type: access, exp: datetime.datetime.utcnow() datetime.timedelta(hoursACCESS_TOKEN_EXPIRES_HOURS), iat: datetime.datetime.utcnow() } new_access_token jwt.encode(new_access_payload, SECRET_KEY, algorithmHS256) return jsonify({code: 200, access_token: new_access_token}), 200要注意的是 Refresh Token 过期后不能自动续否则会出现永远不用重新登录的安全隐患。刷新接口也要加频率限制防止被刷。5. 小程序 / 爬虫 / 数据可视化如何接入这套认证服务5.1 微信小程序端接入流程小程序端不能直接把用户名密码明文放在代码里推荐走wx.login流程前端调用wx.login拿到一次性 code把 code 发给后端的/api/auth/wx_login接口后端用这个 code 向微信服务器换 openid后端查询这个 openid 是否已有绑定用户没有就自动创建后端签发 JWT 返回给小程序小程序把 Token 存到wx.setStorageSync后续请求带上 Authorization 头。这样用户在小程序里点击微信一键登录就能完成认证体验非常贴合真实产品。小程序端发请求时可以用wx.request的 headerwx.request({ url: https://your-auth-service.com/api/auth/userinfo, method: GET, header: { Authorization: Bearer wx.getStorageSync(token) }, success(res) { console.log(res.data); } });5.2 爬虫脚本携带 Token 调接口如果你的毕设里包含爬虫方向最简单的方式是让爬虫先调登录接口换取 Token再带着 Token 去请求受保护的数据接口。用 requests 实现import requests auth_host http://127.0.0.1:5000 # 登录获取 token login_data { username: your_username, password: your_password } resp requests.post(f{auth_host}/api/auth/login, jsonlogin_data) tokens resp.json() access_token tokens[access_token] # 携带 token 请求受保护数据接口 headers { Authorization: fBearer {access_token} } data_resp requests.get(f{auth_host}/api/scrapy/data, headersheaders) print(data_resp.json())这个模式的讲解重点是身份认证和业务采集分离爬虫只负责采集认证服务负责判断这个采集脚本是不是授权客户端。完整代码里我还加了 Token 过期自动刷新逻辑爬虫脚本每跑一段就判断一次是否掉线。这里提醒一句爬虫脚本只能用于你自己的毕设数据采集或者明确允许访问的公开接口一定要遵守目标网站的使用协议和 robots 规则别拿这套去搞违规采集。5.3 用认证日志做数据可视化大屏统一认证服务天生带有日志优势因为所有系统的登录行为都会经过你所以能统计出很多有价值的图表。我用 Flask 把 auth_logs 表的数据开放成 JSON 接口再通过 ECharts 渲染折线图最近 24 小时登录成功/失败趋势饼图登录来源渠道分布网页、小程序、爬虫、APP柱状图各用户登录次数排名地图按 IP 归属地展示登录地区分布这个可以借助 IP 定位库实现。答辩讲数据可视化方向的时候不需要重新做一个复杂系统直接把这一层做成认证安全监控中心把这个可视化界面当做一个子系统来演示老师就会觉得项目的整体性和实用价值特别高。海量想法等都来自这些数据你在答辩时可以说通过监控中心可以实时发现异常登录行为比如同一账号在短时间内从不同地区登录系统会标记为风险事件。6. 我在实际开发中踩过的坑和你大概率也会遇到6.1 跨域问题导致前端一直请求失败前端网页和后端认证服务如果不是同域就会出现跨域。最常见的情况是 Vue 前端在 8080 端口Flask 后端在 5000 端口直接请求会被浏览器拦截。解决方案是给 Flask 应用配置 CORS。我用 Flask-CORS 扩展一行代码解决from flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})但这里有个隐藏坑如果你同时允许跨域和携带 Cookie就不能用*通配符需要指定具体域名并且还要设置supports_credentialsTrue。否则前端登录时明明成功了下一次请求却带不上凭证。小程序测试还好因为小程序的 request 不受浏览器跨域限制但网页端测试一定逃不开这个坑建议提前在配置文件中把允许的域名列表写好。6.2 密码哈希算法让人看不出来对不对第一次做的时候我图省事用hashlib.md5加密同学直接笑我这密码拿去答辩会被老师当场否掉。后来换成werkzeug.security后密码字段变长了数据库存储没有问题。但注意如果你用 Flask-SQLAlchemy 的模型password_hash字段如果定义为String(128)pbkdf2 产生的哈希结果是够放的可别只给String(50)否则入库时报数据超长你排查半天后才想起来是字段长度的问题。6.3 Token 过期时间设计的学问Access Token 太短比如 5 分钟演示时容易中途掉线太长比如 24 小时安全性被质疑。我最终设置成 Access Token 1 小时、Refresh Token 7 天但演示录像里我会临时把 Access Token 过期时间调成 10 分钟以便中途展示过期刷新这一操作。前端也要做好逻辑一般在请求拦截器里判断 401然后调用刷新接口刷新成功后重放原请求。这部分代码在项目里面我写好了但你要理解它为什么要这样做防止用户操作到一半突然被后台踢出体验非常差。6.4 演示录像里最容易翻车的操作顺序录过一遍你就知道最怕的是演示到一半触发数据库约束错误或者 Token 正好过期。我的经验是录像前先在本地完整跑一遍流程把注册、登录、受保护接口访问、跨端同步这几个步骤截图确认演示用的账号密码提前固定且用简单值比如 admin / 123456避免现场输错数据库先导入几条预设数据日志表也有记录这样可视化大屏一打开就有图形不用现场等数据录屏工具用 OBS选择 1080p录完后剪辑掉等待部分最终导出建议压缩到 50MB 以内方便放到毕设说明页面里。我踩的最丢人的坑是录像时忘记清空浏览器缓存导致 Token 被从旧域名自动带过来明明是用 B 账号登录的界面却显示 A 账号的信息。后来我每次录屏前都会先把浏览器缓存和 localStorage 清理一遍。还有一个小技巧演示时不要只开一个终端窗口。我会把认证服务、前端服务、数据库三个窗口并排排列分别打上不同的标题色录像时用鼠标点击不同窗口切换老师一看就知道整个项目是你自己从零搭建的。资源包里我附带了这套编排模板直接照着放就能用。做完这个项目我个人最大的体会是统一身份认证这个东西表面看起来只是一个登录模块但真做起来会发现它牵扯到了前端、后端、数据库、安全、跨端、多人协作、日志监控几乎每一个软件工程环节。它不炫技但非常考察基本功。如果你正在为毕设选头发愁或者手头已经定了这个方向但不知道代码该怎么组织不妨直接把我这份白嫖源码拿去当底子。你需要的核心代码、SQL 建表脚本、小程序登录流程、可视化页面素材都在里面照着跑一遍再按自己的理解改一改答辩时就能讲得清清楚楚了。
最近来问毕设选题的同学特别多十个里有七八个都在犹豫做什么才能既好写又能顺利答辩。我个人的建议非常明确如果你不想被简单管理系统卷死又没精力挑战算法难度那用 Python 做一个统一身份认证服务绝对是性价比很高的选择。它听起来抽象拆开看就是一套让多个系统共用同一份账号密码的登录鉴权中心。这篇就完整聊聊我做完这个项目的思路、代码、踩坑以及如何把它和 JAVA、PHP、小程序、爬虫、数据可视化这些方向串起来作为计算机毕设的完整作品。标题里提到的白嫖源码 演示录像是真的我把自己做完的这套工程整理成了一份可直接运行的毕设资源包里面包含全部源码、数据库脚本、部署说明和演示视频。项目本身不复杂但把认证、鉴权、多端接入、日志可视化这些点全打通之后你会发现它远比XX管理系统这种传统毕设有讲头。下面我把整个项目的设计逻辑和实操过程拆开一步步说清楚。1. 为什么我推荐把统一身份认证作为毕设主项目1.1 它到底解决的是什么问题很多同学一开始不清楚统一身份认证的价值我先用大白话解释一下。假设你同时做了三样东西一个后台管理网站、一个微信小程序商城、一个爬虫采集脚本。按照常见的做法每个系统各自建一张用户表各搞一套注册登录。用户要在三个地方记三套账号密码你自己也要维护三份用户数据改密码得改三处。统一身份认证服务做的事情就是把账号密码这一套东西全部收拢到一个独立服务里。其他系统不再自己注册登录而是通过接口把登录请求转给认证服务。认证服务确认用户身份后签发一个 Token各系统拿着这个 Token 请求受保护的接口。这样一来用户只需要记一个账号所有接入的系统都能用你在任何一处修改密码其他系统立刻生效。这就像写字楼的统一门禁你不需要在每个办公室门口各配一把钥匙只要前台发一张工牌所有能刷的门都能进。毕设答辩时把这个类比讲给老师听对方很快就能 get 到你做的到底是什么。1.2 答辩时的含金量体现在哪里老师评判毕设很看重题目本身有没有技术纵深。写一个图书管理系统讲的内容无非是增删改查翻来覆去没有可扩展的点。但统一身份认证服务这个题目天然带有几个高频考点Token 的生成、解析、过期和刷新机制密码的哈希存储与防暴力破解策略基于角色的访问控制RBAC模型多端接入时的跨域与请求头设计认证日志的采集与可视化展示。每一个拿出来都能单独扩展成一节答辩问题而且都有学术界和工业界的成熟方案可以引用。老师一听就知道你不是在纯堆 CRUD而是接触到了真实后端项目里最核心的模块。1.3 它适配哪些毕设方向我做过一个汇总表格方便你判断自己的方向能不能挂靠这套服务方向在毕设中的角色如何与统一认证结合JAVA / PHP业务系统子端接入认证服务作为受保护的前后端项目微信小程序移动端入口通过 wx.login 换取本地 Token叫醒小程序去访问认证服务爬虫数据采集工具使用认证服务签发的 Token 调用数据接口校验脚本身份APP含 Android/iOS移动客户端登录时调用认证接口存储 Token后续请求携带数据可视化认证日志大屏通过 ECharts 等绘制登录趋势、用户活跃、来源地域分布C# / C 桌面程序桌面客户端用 HTTP 请求接入认证服务完成本地登录状态绑定所以你看自己用什么语言写子系统不关键认证服务能作为公共底座把它们全部串联起来整体作品的故事就完整了。2. 项目功能拆解一台认证服务管住所有系统2.1 最小闭环长什么样做毕设不用一上来就实现 OAuth2、单点登录协议、双因素认证这些东西先跑通一个最小闭环后面再逐步加功能。我建议的最小功能集是注册用户提交用户名和密码服务端校验并存储登录校验用户名密码签发 Access Token 和 Refresh Token校验受保护接口解析请求头里的 Token判断是否有效刷新Access Token 过期后用 Refresh Token 换新的登出将 Token 加入黑名单或删除刷新 Token使其失效用户信息通过 Token 获取当前登录用户的资料。功能列表比想象中短但每一个都可以讲出很多细节。我当时的做法是先把这 6 个接口跑通再补充分页、密码修改、角色分配和日志记录工作量安排非常合理。2.2 多端接入的界面形态为了让老师觉得系统真实可用建议至少做两个端一个 PC 网页管理端一个微信小程序端。网页端用来演示后端管理员功能小程序端用来演示 C 端用户登录。爬虫脚本和数据可视化可以作为补充展示。演示的时候先打开 PC 端的登录页输入刚才注册的账号密码同一个账号再在小程序里登录也能成功而且两边看到的个人信息完全一致这就直观体现了统一的含义。图表数据可以由认证服务记录的日志实时生成展示最近一小时内登录成功的次数和失败次数。2.3 演示录像怎么编排更抓人标题里强调演示录像我建议录像不要从头到尾录操作那样冗长且没有重点。我给你一个可以照抄的脚本痛点引入一句话说传统多系统登录账号不统一的问题启动服务命令行展示认证服务启动数据库连接成功注册账号录注册过程故意输入一次错误密码展示校验逻辑登录成功PC 端登录F12 打开开发者工具展示请求头里的 Token多端同步切换到小程序模拟器用同样的账号登录展示两者信息一致访问受保护接口用 Postman 模拟爬虫脚本调用接口不带 Token 返回 401带 Token 返回数据数据可视化打开日志大屏展示刚才产生的登录记录。这一套录下来大概十分钟节奏紧凑信息量大老师看完就会觉得项目完整度非常高。3. 技术选型与数据库模型不堆技术把基础打结实3.1 Flask 还是 Django很多同学纠结用 Flask 还是 Django我的选择是 Flask。理由是 Flask 足够轻路由和视图函数直观Token 的签发和校验完全由自己控制方便在答辩时把原理说清楚。Django 虽然内置了用户认证系统和 Admin 后台但它把太多细节封装掉了你很难在答辩时解释Token 到底在里面是怎么流转的。如果学校要求必须用企业级框架Django 也完全可以跑只是需要在配置里替换默认的 session 认证方案改成自定义的 JWT 中间件。两者对比大致如下对比项Flask JWTDjango 自定义认证上手速度快核心逻辑全透明较快但嵌套封装多默认功能少自己补多自带 Admin答辩讲述容易讲清 Token 原理容易扯到 Django 内部机制适合场景演示为主加分项很多的项目我自己最终选了 Flask SQLAlchemy PyJWT代码量不大架构足够清晰。3.2 数据库表设计数据库我设计成五张核心表用户表users、角色表roles、权限表permissions、用户角色关联表user_roles、角色权限关联表role_permissions。另外加了两张辅助表客户端应用表applications和认证日志表auth_logs。用户表主要字段如下CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username VARCHAR(64) UNIQUE NOT NULL, password_hash VARCHAR(128) NOT NULL, email VARCHAR(120), is_active BOOLEAN DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );password_hash 存的是哈希后的密码绝不存明文。auth_logs 表用来记录每次登录/登出的 IP、时间、结果、操作类型后面可视化就用它当数据源。3.3 密码加密方案千万不要用 MD5 或者明文存密码这是毕设答辩里最容易被老师一眼看穿的扣分点。我用的是 Werkzeug 自带的generate_password_hash默认算法是 pbkdf2:sha256内部自动加盐。这样做的好处是每次哈希结果都带随机盐同样密码两次哈希结果不一样校验时调用check_password_hash自动把盐提取出来重新计算攻击者即使拿到数据库也无法反推明文。如果你出于学习目的想自己实现至少也要用hashlib.pbkdf2_hmac做几千次迭代加盐不要把简单sha256(password)这种东西写进项目。4. 核心代码实现从注册登录到单点登录的完整链路4.1 注册接口与密码哈希注册接口的核心逻辑非常简单接收用户名、密码判断用户名是否已存在然后用哈希函数处理密码存入数据库。示例代码如下from werkzeug.security import generate_password_hash from flask import request, jsonify from models import User, db app.route(/api/auth/register, methods[POST]) def register(): data request.get_json() username data.get(username) password data.get(password) if not username or not password: return jsonify({code: 400, msg: 用户名和密码不能为空}), 400 if User.query.filter_by(usernameusername).first(): return jsonify({code: 400, msg: 用户名已存在}), 400 user User( usernameusername, password_hashgenerate_password_hash(password) ) db.session.add(user) db.session.commit() return jsonify({code: 201, msg: 注册成功}), 201我建议在注册接口里加上用户名长度检查、密码必须包含字母和数字等校验逻辑因为老师在答辩时经常先看接口健壮性而不是先看前端界面。4.2 登录接口与 JWT 签发登录接口执行两件事验证凭证签发 Token。JWT 我用 PyJWT 库生成PayLoad 里放用户 ID、用户名、角色信息设置过期时间。关键代码如下import jwt import datetime from werkzeug.security import check_password_hash SECRET_KEY your_secret_key ACCESS_TOKEN_EXPIRES_HOURS 1 REFRESH_TOKEN_EXPIRES_DAYS 7 app.route(/api/auth/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) user User.query.filter_by(usernameusername).first() if not user or not check_password_hash(user.password_hash, password): return jsonify({code: 401, msg: 用户名或密码错误}), 401 if not user.is_active: return jsonify({code: 403, msg: 账号已被禁用}), 403 access_payload { sub: user.id, username: user.username, type: access, exp: datetime.datetime.utcnow() datetime.timedelta(hoursACCESS_TOKEN_EXPIRES_HOURS), iat: datetime.datetime.utcnow() } refresh_payload { sub: user.id, type: refresh, exp: datetime.datetime.utcnow() datetime.timedelta(daysREFRESH_TOKEN_EXPIRES_DAYS), iat: datetime.datetime.utcnow() } access_token jwt.encode(access_payload, SECRET_KEY, algorithmHS256) refresh_token jwt.encode(refresh_payload, SECRET_KEY, algorithmHS256) return jsonify({ code: 200, msg: 登录成功, access_token: access_token, refresh_token: refresh_token, user: {id: user.id, username: user.username} }), 200这里的小细节是把iat设置为签发时间exp设置为过期时间。后面校验时 PyJWT 会自动校验exp一旦过期会抛出ExpiredSignatureError。4.3 鉴权装饰器与接口保护受保护接口的鉴权逻辑可以封装成一个装饰器这样每个视图只需要在上面加一行require_auth即可。装饰器解析请求头里Authorization: Bearer token解码后把用户信息挂到request.current_user上。from functools import wraps from flask import request, jsonify import jwt def require_auth(f): wraps(f) def decorated(*args, **kwargs): auth_header request.headers.get(Authorization) if not auth_header or not auth_header.startswith(Bearer ): return jsonify({code: 401, msg: 缺少访问令牌}), 401 token auth_header.split( )[1] try: payload jwt.decode(token, SECRET_KEY, algorithms[HS256]) if payload.get(type) ! access: return jsonify({code: 401, msg: 令牌类型错误}), 401 request.current_user { id: payload.get(sub), username: payload.get(username) } except jwt.ExpiredSignatureError: return jsonify({code: 401, msg: 令牌已过期}), 401 except jwt.InvalidTokenError: return jsonify({code: 401, msg: 无效令牌}), 401 return f(*args, **kwargs) return decorated在做接口保护演示时先不带 Token 请求返回 401再带 Token 请求返回正常数据。这一步非常直观建议录像时专门录一小段。4.4 单点登录的实操方案真正的企业级单点登录SSO涉及 CAS、OAuth2、OIDC 等协议比较复杂。毕设阶段只需要实现多个应用共用一个认证中心的精简版即可。我的实现思路是这样的所有接入系统把 Token 存放在各自的前端存储中网页是 localStorage小程序是 wx.storage每个受保护接口都统一调用认证服务的/api/auth/introspect接口或本地验证 JWT 签名只要所有系统的 JWT 使用同一个 SECRET_KEY 签发和验证任意一个系统签发的 Token其他系统都能识别。这样同一账号在多系统间保持登录的效果就实现了。更简单的方式是在同一个域名下部署多个前端子应用这样 localStorage 本来就是共享的。如果要做跨域名可以用 iframe postMessage 实现 Token 中转但那里坑比较多我建议毕设别做那么深除非老师明确要求。4.5 刷新 Token 与自动登录Access Token 设置 1 小时过期Refresh Token 设置 7 天过期。前端发请求时如果收到 401再用 Refresh Token 调用刷新接口换新 Token。代码如下app.route(/api/auth/refresh, methods[POST]) def refresh(): data request.get_json() refresh_token data.get(refresh_token) if not refresh_token: return jsonify({code: 400, msg: 缺少刷新令牌}), 400 try: payload jwt.decode(refresh_token, SECRET_KEY, algorithms[HS256]) if payload.get(type) ! refresh: return jsonify({code: 401, msg: 刷新令牌类型错误}), 401 except jwt.InvalidTokenError: return jsonify({code: 401, msg: 刷新令牌无效}), 401 user User.query.get(payload.get(sub)) if not user: return jsonify({code: 401, msg: 用户不存在}), 401 new_access_payload { sub: user.id, username: user.username, type: access, exp: datetime.datetime.utcnow() datetime.timedelta(hoursACCESS_TOKEN_EXPIRES_HOURS), iat: datetime.datetime.utcnow() } new_access_token jwt.encode(new_access_payload, SECRET_KEY, algorithmHS256) return jsonify({code: 200, access_token: new_access_token}), 200要注意的是 Refresh Token 过期后不能自动续否则会出现永远不用重新登录的安全隐患。刷新接口也要加频率限制防止被刷。5. 小程序 / 爬虫 / 数据可视化如何接入这套认证服务5.1 微信小程序端接入流程小程序端不能直接把用户名密码明文放在代码里推荐走wx.login流程前端调用wx.login拿到一次性 code把 code 发给后端的/api/auth/wx_login接口后端用这个 code 向微信服务器换 openid后端查询这个 openid 是否已有绑定用户没有就自动创建后端签发 JWT 返回给小程序小程序把 Token 存到wx.setStorageSync后续请求带上 Authorization 头。这样用户在小程序里点击微信一键登录就能完成认证体验非常贴合真实产品。小程序端发请求时可以用wx.request的 headerwx.request({ url: https://your-auth-service.com/api/auth/userinfo, method: GET, header: { Authorization: Bearer wx.getStorageSync(token) }, success(res) { console.log(res.data); } });5.2 爬虫脚本携带 Token 调接口如果你的毕设里包含爬虫方向最简单的方式是让爬虫先调登录接口换取 Token再带着 Token 去请求受保护的数据接口。用 requests 实现import requests auth_host http://127.0.0.1:5000 # 登录获取 token login_data { username: your_username, password: your_password } resp requests.post(f{auth_host}/api/auth/login, jsonlogin_data) tokens resp.json() access_token tokens[access_token] # 携带 token 请求受保护数据接口 headers { Authorization: fBearer {access_token} } data_resp requests.get(f{auth_host}/api/scrapy/data, headersheaders) print(data_resp.json())这个模式的讲解重点是身份认证和业务采集分离爬虫只负责采集认证服务负责判断这个采集脚本是不是授权客户端。完整代码里我还加了 Token 过期自动刷新逻辑爬虫脚本每跑一段就判断一次是否掉线。这里提醒一句爬虫脚本只能用于你自己的毕设数据采集或者明确允许访问的公开接口一定要遵守目标网站的使用协议和 robots 规则别拿这套去搞违规采集。5.3 用认证日志做数据可视化大屏统一认证服务天生带有日志优势因为所有系统的登录行为都会经过你所以能统计出很多有价值的图表。我用 Flask 把 auth_logs 表的数据开放成 JSON 接口再通过 ECharts 渲染折线图最近 24 小时登录成功/失败趋势饼图登录来源渠道分布网页、小程序、爬虫、APP柱状图各用户登录次数排名地图按 IP 归属地展示登录地区分布这个可以借助 IP 定位库实现。答辩讲数据可视化方向的时候不需要重新做一个复杂系统直接把这一层做成认证安全监控中心把这个可视化界面当做一个子系统来演示老师就会觉得项目的整体性和实用价值特别高。海量想法等都来自这些数据你在答辩时可以说通过监控中心可以实时发现异常登录行为比如同一账号在短时间内从不同地区登录系统会标记为风险事件。6. 我在实际开发中踩过的坑和你大概率也会遇到6.1 跨域问题导致前端一直请求失败前端网页和后端认证服务如果不是同域就会出现跨域。最常见的情况是 Vue 前端在 8080 端口Flask 后端在 5000 端口直接请求会被浏览器拦截。解决方案是给 Flask 应用配置 CORS。我用 Flask-CORS 扩展一行代码解决from flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})但这里有个隐藏坑如果你同时允许跨域和携带 Cookie就不能用*通配符需要指定具体域名并且还要设置supports_credentialsTrue。否则前端登录时明明成功了下一次请求却带不上凭证。小程序测试还好因为小程序的 request 不受浏览器跨域限制但网页端测试一定逃不开这个坑建议提前在配置文件中把允许的域名列表写好。6.2 密码哈希算法让人看不出来对不对第一次做的时候我图省事用hashlib.md5加密同学直接笑我这密码拿去答辩会被老师当场否掉。后来换成werkzeug.security后密码字段变长了数据库存储没有问题。但注意如果你用 Flask-SQLAlchemy 的模型password_hash字段如果定义为String(128)pbkdf2 产生的哈希结果是够放的可别只给String(50)否则入库时报数据超长你排查半天后才想起来是字段长度的问题。6.3 Token 过期时间设计的学问Access Token 太短比如 5 分钟演示时容易中途掉线太长比如 24 小时安全性被质疑。我最终设置成 Access Token 1 小时、Refresh Token 7 天但演示录像里我会临时把 Access Token 过期时间调成 10 分钟以便中途展示过期刷新这一操作。前端也要做好逻辑一般在请求拦截器里判断 401然后调用刷新接口刷新成功后重放原请求。这部分代码在项目里面我写好了但你要理解它为什么要这样做防止用户操作到一半突然被后台踢出体验非常差。6.4 演示录像里最容易翻车的操作顺序录过一遍你就知道最怕的是演示到一半触发数据库约束错误或者 Token 正好过期。我的经验是录像前先在本地完整跑一遍流程把注册、登录、受保护接口访问、跨端同步这几个步骤截图确认演示用的账号密码提前固定且用简单值比如 admin / 123456避免现场输错数据库先导入几条预设数据日志表也有记录这样可视化大屏一打开就有图形不用现场等数据录屏工具用 OBS选择 1080p录完后剪辑掉等待部分最终导出建议压缩到 50MB 以内方便放到毕设说明页面里。我踩的最丢人的坑是录像时忘记清空浏览器缓存导致 Token 被从旧域名自动带过来明明是用 B 账号登录的界面却显示 A 账号的信息。后来我每次录屏前都会先把浏览器缓存和 localStorage 清理一遍。还有一个小技巧演示时不要只开一个终端窗口。我会把认证服务、前端服务、数据库三个窗口并排排列分别打上不同的标题色录像时用鼠标点击不同窗口切换老师一看就知道整个项目是你自己从零搭建的。资源包里我附带了这套编排模板直接照着放就能用。做完这个项目我个人最大的体会是统一身份认证这个东西表面看起来只是一个登录模块但真做起来会发现它牵扯到了前端、后端、数据库、安全、跨端、多人协作、日志监控几乎每一个软件工程环节。它不炫技但非常考察基本功。如果你正在为毕设选头发愁或者手头已经定了这个方向但不知道代码该怎么组织不妨直接把我这份白嫖源码拿去当底子。你需要的核心代码、SQL 建表脚本、小程序登录流程、可视化页面素材都在里面照着跑一遍再按自己的理解改一改答辩时就能讲得清清楚楚了。
![[matlab]重写NewCallback让scatter3数据游标cursor显示点值：TaoToken统一Key接入AI辅助调试](http://pic.xiahunao.cn/yaotu/[matlab]重写NewCallback让scatter3数据游标cursor显示点值：TaoToken统一Key接入AI辅助调试)
