人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载本指南围绕 gsd-2 仓库中内置的 Vercel React/Next.js 最佳实践技能react-best-practices的server-auth-actions规则展开解决一个常见却危险的问题Server Actions 被当作公开 HTTP 端点暴露任何未认证用户都可以直接调用。读完本文你将掌握在 action 内部完成认证 授权 输入校验的完整写法并理解为什么 middleware、布局守卫和页面级检查都无法替代 action 内的第一道安全防线。规则出处与定位该规则位于仓库的 react-best-practices 技能包 下具体文件为 rules/server-auth-actions.md。根据技能的 SKILL.md 与 metadata.json这套指南由 Vercel Engineering 维护共 57 条规则、8 大分类按影响优先级排列优先级分类影响前缀1消除 WaterfallCRITICALasync-2Bundle 体积优化CRITICALbundle-3服务端性能HIGHserver-4客户端数据获取MEDIUM-HIGHclient-5重渲染优化MEDIUMrerender-6渲染性能MEDIUMrendering-7JavaScript 性能LOW-MEDIUMjs-8进阶模式LOWadvanced-server-auth-actions属于第 3 类服务端性能Server-Side Performance但其impact字段标注为CRITICALimpactDescription为prevents unauthorized access to server mutations防止未授权访问服务端写操作——它是该分类中唯一的 CRITICAL 级规则因为它保护的并非性能而是数据安全本身。核心事实Server Actions 就是公开端点Next.js 中凡是带有use server指令的函数即 Server Actions编译后都会被框架自动暴露为可供客户端 HTTP 调用的端点endpoint。这意味着任何知道 action 标识符的人都可以绕过 UI 直接发起调用正如可以绕过页面直接 POST 到 API 路由一样前端页面上的按钮只是其中一个调用方绝不是唯一调用方因此页面级检查、布局守卫、middleware 都只是用户体验层的拦截不是安全边界——真正的安全边界必须落在 action 自身内部。Next.js 官方文档对此有明确表述Treat Server Actions with the same security considerations as public-facing API endpoints, and verify if the user is allowed to perform a mutation.应当像对待面向公众的 API 端点一样对待 Server Actions并验证用户是否被允许执行该写操作。这正是本规则的立论依据。错误示范没有任何认证检查的写操作规则首先给出了一个典型的错误实现——deleteUser直接对数据库执行删除use server export async function deleteUser(userId: string) { // Anyone can call this! No auth check await db.user.delete({ where: { id: userId } }) return { success: true } }这段代码的问题一目了然函数被导出为 Server Action 后等同于一个无需任何凭证即可调用的公开接口。任何能够拿到 action 引用例如通过网络请求分析、源码映射或对编译产物进行探测的攻击者都可以随意删除任意用户。规则对此的评语是Anyone can call this!——没有认证检查的 mutation 是最高危的安全缺陷。正确示范在 action 内部完成认证与授权正确做法是把verifySession()的校验放进每个 action 内部并且在认证通过后再做一层**授权authorization**判断——认证回答你是谁授权回答你是否有权做这件事use server import { verifySession } from /lib/auth import { unauthorized } from /lib/errors export async function deleteUser(userId: string) { // Always check auth inside the action const session await verifySession() if (!session) { throw unauthorized(Must be logged in) } // Check authorization too if (session.user.role ! admin session.user.id ! userId) { throw unauthorized(Cannot delete other users) } await db.user.delete({ where: { id: userId } }) return { success: true } }这段示例体现了三条关键实践认证前置第一行就调用verifySession()未登录直接抛出unauthorized绝不执行后续任何业务逻辑授权细分仅已登录不够还需判断角色role admin或所有权user.id userId。管理员可以删除任意用户普通用户只能删除自己——这是对象级授权object-level authorization的典型写法统一错误语义通过自定义的unauthorized错误类型抛出统一的 401 语义便于前端和日志系统一致地识别处理。纵深防御认证、授权、输入校验三步走如果 action 接收外部输入规则进一步要求在认证之前先完成输入校验整体遵循 Validate → Authenticate → Authorize → Mutate 的固定顺序。使用zod对未知类型输入做运行时校验是推荐做法use server import { verifySession } from /lib/auth import { z } from zod const updateProfileSchema z.object({ userId: z.string().uuid(), name: z.string().min(1).max(100), email: z.string().email() }) export async function updateProfile(data: unknown) { // Validate input first const validated updateProfileSchema.parse(data) // Then authenticate const session await verifySession() if (!session) { throw new Error(Unauthorized) } // Then authorize if (session.user.id ! validated.userId) { throw new Error(Can only update own profile) } // Finally perform the mutation await db.user.update({ where: { id: validated.userId }, data: { name: validated.name, email: validated.email } }) return { success: true } }注意data的类型被声明为unknown——这正是 zod 的核心使用场景Server Action 的入参来自客户端网络请求属于不可信数据必须先经过updateProfileSchema.parse()强制出结构正确的对象才能安全进入后续逻辑。schema 中的约束本身就是活文档userId: z.string().uuid()—— 强制 UUID 格式拒绝任意字符串注入name: z.string().min(1).max(100)—— 长度上下限防脏数据入库email: z.string().email()—— 格式校验。校验完成后才做认证verifySession与授权session.user.id ! validated.userId拒绝越权修改他人资料最后才触碰数据库。这四条顺序一旦颠倒就可能出现先查询后拦截或先写入后校验的漏洞窗口。为什么不能只依赖 middleware / 布局守卫从源码结构看Next.js 的 middleware 运行在边缘层、页面守卫与布局检查运行在渲染层它们都无法覆盖直接调用 action这一路径。这带来两点现实结论middleware 适合做前置的粗粒度过滤如封禁 IP、全局登录跳转但不应被视为安全边界它拦截不了绕过路由系统直达 action 的调用也容易因配置遗漏而出现看似保护了所有路由、唯独漏掉某个 action的局面布局与页面守卫只能保护 UI 可见性如未登录用户看不到管理按钮属于体验层而非安全层。攻击者不经过 UI守卫就形同虚设。因此规则给出的硬性要求是在每一个会执行写操作mutation的 Server Action 内部重复进行认证与授权检查。虽然这看起来是重复代码但它是唯一能确保无论调用来自哪条路径都生效的兜底防线。结合同技能的相邻规则让认证查询更高效server-auth-actions并非孤立规则。同属server-前缀的 server-cache-react.md 指出认证检查authentication checks正是React.cache()每请求去重的最典型受益场景页面、多个 Server Component 与多个 Server Action 在同一请求内各自调用verifySession()时可以通过cache()让整条请求只执行一次会话查询import { cache } from react export const getCurrentUser cache(async () { const session await auth() if (!session?.user?.id) return null return await db.user.findUnique({ where: { id: session.user.id } }) })把认证逻辑包装进cache()后同一请求内多次调用只会触发一次数据库查询既保留了每个 action 内部都要鉴权的安全语义又消除了重复查询的开销——安全与性能在这个模式中可以兼得。需要留意的是React.cache()基于参数浅比较判断缓存命中若必须传对象参数应传入同一引用参见同文件中的示例说明。仓库中的落地方式技能打包与触发测试在本仓库中react-best-practices并非一份孤立文档而是被集成进 gsd 的扩展技能体系src/resources/extensions/gsd/bootstrap/system-context.ts 中注册了触发词React/Next.js performance — components, data fetching, bundle optimization, rendering patterns from Vercel Engineering当 Agent 进入 React/Next.js 代码相关任务时自动匹配react-best-practices技能src/resources/extensions/gsd/skill-catalog.ts 的React Web Frontend目录将vercel-react-best-practices归入官方技能源并按matchLanguages: [javascript/typescript]匹配 TS/JS 项目src/resources/extensions/gsd/tests/bundled-skill-triggers.test.ts 将react-best-practices列入内置技能清单由测试断言其触发词被正确注册。这意味着该规则的实际用途是指导 Agent 在编写、审查或重构 React/Next.js 代码时自动套用安全模式当生成的 Server Action 缺少内部鉴权时应当依据此规则补上认证与授权代码而不是仅依赖 middleware 等外部机制。实施自查清单把本规则落地到自己的项目时可以按以下清单逐项核对每个use server导出函数都以会话校验开头未认证即抛unauthorized不执行任何后续逻辑授权判断覆盖对象级权限不仅检查是否登录还检查角色/资源所有权如session.user.id ! targetId时拒绝所有外部输入先经 schema 校验推荐 zod入参类型声明为unknown且校验先于认证、认证先于授权、授权先于写操作错误语义统一认证/授权失败使用可识别的 401 类错误便于前端统一处理如跳转登录页middleware / 布局守卫仅作辅助可保留作为体验优化但绝不在安全上依赖它们认证查询做去重对会话/用户查询使用React.cache()或依赖 Next.js 对fetch的自动 memoization避免同一请求内重复查询。将server-auth-actions与仓库中的 server-serialization.md、server-cache-react.md 等规则组合使用就能在 Server Actions 这一侧同时守住安全、性能与数据体积三条线。核心心法只有一句Server Actions 没有内部与外部之分每个 action 都是面向公众的入口鉴权必须发生在入口本身。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐QuickRecorder macOS 录屏工具教程从安装到第一次录制QuickRecorder macOS 录屏工具教程从安装到第一次录制 QuickRecorder 是一款基于系统 ScreenCapture Kit 开发的桌面应用音视频屏幕录制ROG 屏幕发白不用愁G-Helper 色彩修复实战ROG 屏幕发白不用愁G Helper 色彩修复实战 如果你发现 ROG 或华硕笔记本屏幕最近发白、颜色发灰切换色彩模式又没反应先别急着怀疑硬件。多数情况开发工具AI 应用代码智能体像 API 路由一样为 Server Actions 鉴权Next.js 服务端操作安全实践像 API 路由一样为 Server Actions 鉴权Next.js 服务端操作安全实践 Server Action use server 函数与音视频桌面应用后端上一篇Notero深度解析Zotero与Notion双向同步的架构设计与实战指南下一篇如何快速部署微信机器人5分钟打造专属智能助手完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
