最近在整理项目里的认证链路。发现一个很容易被忽略的小坑：页面未登录可以跳登录页，但 API 未登录千万别直接跳登录页。

听起来像废话，但我一开始确实差点这么干。毕竟在传统 Web 里使用者访问 /ordersCookie 过期了服务端会自动重定向到 /login浏览器跟着过去，体验挺顺的。

问题出在 Leptos server function。它发起的是接口请求，它期待的是一段可反序列化的响应。而不是登录页 HTML，你要是让 API 也重定向到 /login前端最终可能拿到一整页 HTML，接下来报一个莫名其妙的反序列化失败。使用者看到的不是“登录过期”，而是“数据格式错误”。这就很尴尬，

痛点汇总

• 接口返回页面导致前端报错：“数据格式错误”
• 使用者体验被破坏：无法清晰知道是需要重新登录还是出现了其他异常
• 调试难度大的观点是，日志里只看到 302 重定向。却不知道原因来自哪里
• 说到安全边界模糊，不同角色混用同一登陆入口导致权限泄露风险

一、先看路由挂载：认证在 Axum 中间件里统一进来

Pico-CRM 是 Rust 全栈项目，后端用 Axum，页面用 Leptos SSR + WASM hydration。认证中间件挂在 Router 上：

let app = Router::new
.leptos_routes_with_context(
&leptos_options。routes,move || {
provide_context);},{
let leptos_options = leptos_options.clone;move || shell)
},)
.layer)
.fallback)
.with_state;

这里用的是 from_fn_with_state因为认证不只是看 Cookie，还要用数据库连接做两件事：

• 校验 JWT 对应的使用者是否仍然有效
• 校验商户状态是否 active 且没有过期

这也是为什么我没有把认证逻辑散落到每个 server function 里。中间件先把“这个请求到底是不是合法使用者发来的”处理掉，业务 handler 后面只关心业务本身。

二、白名单：登录接口自己不能被登录拦住

中间件第一步先不是解析 JWT，而是先判断白名单：

let white_list =;
if white_list.contains) {
return Ok.await);}

This snippet solves a very practical problem: login pages,admin login pages。and merchant registration endpoints must not require an existing session.

Pico‑CRM 有两套入口：

• 普通商户使用者：/login、/api/login
• 网站管理员：/admin/login、/api/admin/login

白名单里必须同时放页面路由和 API 路由。否则最典型的事故就是：使用者访问登录页。登录页自己被中间件重定向到同一个地址，导致原地打转。

三、页面通道：浏览器请求适合

页面请求的处理逻辑比较符合直觉：没登录就跳转到对应的登陆页。

辅助函数示例——决定跳转哪条方法：

fn login_path_for -> &'static str {
if path.starts_with || path.starts_with {
"/admin/login"
} else {
"/login"
}
}

为什么要区分？

• “网站管理员和商户使用者是两个世界”；管理员去 /admin 时应该回 /admin/login；商户使用者去 /orders 时应该回 /login。
• If you unify m,UX gets confusing and permission boundaries blur.

返回重定向 Response 的实现：

let login_path = login_path_for;let mut res = Response::new);*res.status_mut = StatusCode::SEE_OTHER;res.headers_mut.insert(
再看axum:。http::header::LOCATION,HeaderValue::from_static,);Ok

I chose,not just any status code. It explicitly tells client to issue a GET request to anor URL,which is safer when dealing with POSTs or or state‑changing actions that failed auntication.

& 常用方法提示

• Avoid redirecting APIs to HTML pages—return clear JSON error codes like {"error":"unaunticated"。"redirect":"/login"}.
• Create a dedicated “auth middleware” that runs before any business logic and checks both JWT validity and merchant status.
• Delineate separate white‑list paths for front‑end pages and back‑end APIs per role.
• Satisfy page requests with proper redirects .
• Add explicit headers ) so front‑end can handle redirects programmatically if needed.

希望这些细节能帮你避免常见的 Auth 重定向陷阱，让前后端分离时保持清晰、稳健的数据流与安全边界。