Cursor用户花4小时踩坑后，这套认证流程让他再没翻车

上个月有个独立开发者花了整整4小时，追踪一个"随机登出"的bug。最后发现，问题不是OAuth多复杂，而是他在3个不同地方读取了session，每个地方的假设都差那么一点点。

这哥们用Cursor+Claude写代码，第一版快得像开挂。但第一版会撒谎——happy path跑得通，开第二个标签页登出，界面却还显示已登录。AI生成的代码像新手厨师，摆盘漂亮，火候全靠运气。

后来他固定了一套流程：生成→集中→模糊测试→验证。四步走，每次如此。今天这篇就是他的实战笔记，专门治AI写认证时的"选择性诚实"。

第一步：把session读取关进一个笼子

如果你在5个文件里读cookie，你已经输了。

他的规矩是：一个模块，一个导出函数，其他全部调用它。Next.js App Router里，这个笼子叫lib/session.ts，server-only。

代码结构长这样：从cookie取token，base64url解码，JSON解析，然后硬检查——userId有没有、email有没有、roles是不是数组、expiresAt是不是数字、过期没。最后顺手绑个user-agent防重放。

失败全部返回null，没有"差不多就行"。

关键认知：这不是"安全认证"，这是结构。每个请求走同一套门，改cookie格式只改一个文件。

Cursor曾经给他生成过JSON.parse(cookies().get(...))，没try/catch。结果用户的过期cookie直接让页面崩溃。AI不会替你考虑脏数据，你得自己设防。

第二步：middleware只做一道选择题

他以前爱在middleware里塞太多逻辑。然后掉进重定向循环，调试体验堪比解绳结。

现在的middleware只回答一个问题：这个请求能碰/app吗？

不取用户资料，不刷新token，不调用Supabase。就查cookie在不在，不在就踢去登录页。代码控制在10行以内，像保安查工牌，不查你包里装什么。

业务逻辑扔到server action或route handler里。middleware越瘦，半夜收报警的概率越低。

第三步：用AI生成"混乱"来测试

认证最怕的不是黑客，是自己漏掉的边缘情况。

他的fuzz策略是让Claude生成测试用例：过期token、格式错误的JSON、缺失字段、超大payload、emoji混入的email。然后批量跑，看哪个能让getSession()崩溃或撒谎。

上个月那4小时，大部分浪费在"错误地修错误"——改A处，B处又坏。根源就是读取点太分散。集中之后，fuzz只要锤一个点。

他给Cursor的prompt模板："生成10个恶意或边缘的session token变体，测试这个函数的鲁棒性。"

AI写测试比写生产代码更靠谱，因为它擅长穷举，不擅长权衡。

第四步：人工走一遍"用户会做的事"

自动化测试完，他固定做一个动作：开两个浏览器，A登录、B登出、回A刷新、看状态是否一致。再试试直接改cookie过期时间、清掉user-agent、在登录页点后退按钮。

这些动作没有自动化，因为用户的"不合理"操作太难预测。AI能帮你写代码，不能替你做用户。

他的时间账：生成代码10分钟，集中重构20分钟，fuzz测试15分钟，人工走查10分钟。总投入55分钟，换来之后零次认证相关的线上故障。

对比上个月：4小时救火，加后续用户投诉，加声誉损失。这笔账，小学数学水平都能算清。

这套流程的隐藏收益是，团队成员（或未来的自己）看到lib/session.ts就知道认证怎么工作。没有"这部分在middleware，那部分在API route，还有部分在客户端hook"的寻宝游戏。

文档即代码，代码即约束。

他在文末留了个问题：你最近一次认证bug，花了多久定位？是代码问题，还是结构问题？