2.1 out 方法#

源码节选：

• 路径：duolaimall-gateway/src/main/java/com/cskaoyan/mall/gateway/filter/AuthFilter.java
• 类与方法：AuthFilter#out

1
Result<Object> result =
2
        Result.build(null, resultCodeEnum);
3

4
byte[] bits =
5
        JSONObject.toJSONString(result)
6
                  .getBytes(StandardCharsets.UTF_8);
7

8
DataBuffer wrap =
9
        response.bufferFactory().wrap(bits);
10

11
response.getHeaders().add(
12
        "Content-Type",
13
        "application/json;charset=UTF-8"
14
);
15

16
return response.writeWith(Mono.just(wrap));

两个业务码来自 ResultCodeEnum：

这里的 204 是 JSON 中的业务 code，不等同于 HTTP 204 No Content。

2.2 HTTP 状态码边界#

out 方法没有调用 response.setStatusCode。

因此，当前客户端主要依赖 Result.code 区分鉴权错误；实际 HTTP 状态是否保持默认值，本轮没有运行确认。

不能把当前实现描述成“Gateway 返回 HTTP 401”，因为代码里没有设置 401。

这正是本项目与很多 JWT 教程实现的一个明显差异。

3.1 登录阶段如何取 IP#

UserController 调用：

1
String ip =
2
        IpUtil.getIpAddress(request);

Servlet 版本的选择顺序可以概括为：

1
x-forwarded-for
2
  -> Proxy-Client-IP
3
  -> WL-Proxy-Client-IP
4
  -> request.remoteAddr
5
  -> 如果是 IPv4 回环地址，则尝试本机网卡地址
6
  -> 多代理时取逗号前第一段

3.2 Gateway 阶段如何取 IP#

Gateway 调用：

1
String nowIp =
2
        IpUtil.getGatwayIpAddress(request);

Reactive 版本还会依次检查：

• HTTP_CLIENT_IP；
• HTTP_X_FORWARDED_FOR；
• X-Real-IP；
• 最后使用 remoteAddress。

登录端和网关端的提取规则并非完全相同。

3.3 IP 绑定带来的收益#

如果攻击者只拿到了 Token，但请求来源 IP 与登录 IP 不同，Gateway 会返回非法请求。

这为 Token 泄漏增加了一道使用条件。

3.4 IP 绑定的边界#

生产环境通常需要由受信任代理统一清洗并重写转发头，应用只信任约定好的来源。

当前仓库没有部署拓扑和可信代理配置证据，因此不能确认 IP 绑定在真实网络中的有效性。

4.1 AuthContext 不是 ThreadLocal#

源码：

• 路径：duolaimall-common/common-util/src/main/java/com/cskaoyan/mall/common/util/AuthContext.java
• 类：AuthContext

1
public static String getUserId(
2
        HttpServletRequest request
3
) {
4
    String userId =
5
            request.getHeader("userId");
6

7
    return StringUtils.isEmpty(userId)
8
            ? ""
9
            : userId;
10
}
11

12
public static String getUserTempId(
13
        HttpServletRequest request
14
) {
15
    String userTempId =
16
            request.getHeader("userTempId");
17

18
    return StringUtils.isEmpty(userTempId)
19
            ? ""
20
            : userTempId;
21
}

AuthContext 只是请求头读取工具：

• 不保存 ThreadLocal；
• 不查询 Redis；
• 不验证 Token；
• 缺失时返回空字符串，不返回 null。

因此它依赖一个前提：请求确实经过可信 Gateway，而且 userId Header 已经过正确清洗与重建。

4.2 购物车的实际消费入口#

源码节选：

• 路径：duolaimall-cart/cart-service/src/main/java/com/cskaoyan/mall/cart/controller/CartController.java
• 类与方法：CartController#cartList

1
String userId =
2
        AuthContext.getUserId(request);
3

4
String userTempId =
5
        AuthContext.getUserTempId(request);
6

7
List<CartInfoDTO> cartList =
8
        cartService.getCartList(
9
                userId,
10
                userTempId
11
        );

这就是身份透传与购物车合并链路的连接点：

• 登录用户有 userId；
• 游客可能只有 userTempId；
• 刚登录用户可能同时携带两者；
• CartService 再决定正式购物车和临时购物车如何合并。

4.3 秒杀的实际消费入口#

PromoController 的多个受保护接口调用 AuthContext.getUserId。

例如获取秒杀下单码时，代码从请求头取得 userId，再把它用于生成用户相关下单码。

这说明 Gateway 的 userId 不只是展示信息，而会进入后续业务标识计算。

因此，身份头的可信来源和服务是否可绕过 Gateway 是整个系统的重要安全边界。

5.1 仓库内 application.yml 能确认什么#

user-service 与 server-gateway 都声明：

• spring.application.name；
• dev profile；
• Nacos discovery；
• Nacos config；
• 服务专属配置导入；
• common.yaml 导入。

脱敏后的结构语义如下：

1
spring:
2
  application:
3
    name: <service-user 或 server-gateway>
4
  profiles:
5
    active: dev
6
  cloud:
7
    nacos:
8
      discovery:
9
        server-addr: <由本机或环境配置>
10
      config:
11
        server-addr: <由本机或环境配置>
12
        file-extension: yaml
13
  config:
14
    import:
15
      - nacos:<service-name>-<profile>.yaml
16
      - nacos:common.yaml

这是用途示意，不复制仓库中的具体地址、账号或密码。

5.2 本链路依赖的外部属性#

本轮没有读取 Nacos 中的实际值，也没有连接任何外部基础设施。

6.1 已确认实现与边界矩阵#

6.2 Redis 不可用时会怎样#

Gateway 的 hasLogin 直接调用 bucket.get，代码中没有：

• 本地会话缓存；
• Redis 异常降级；
• 超时后的匿名回退；
• 熔断或隔离逻辑；
• 对受保护接口的备用认证源。

安全上不应该在 Redis 异常时默认放行。

当前异常最终如何呈现还取决于 Gateway 全局异常处理，本轮没有运行验证。

6.3 登录并发#

多个并发登录请求之间没有共享用户级锁，也没有按 userId 覆盖旧会话。

正常情况下，每个请求取得不同雪花 ID并写不同 Key，互不覆盖。

真正需要关注的是雪花节点配置是否唯一。如果不同实例错误使用同一节点标识并产生相同 ID，后写入会覆盖同名 Key。

这是一项配置层候选风险，不是当前已复现问题。

6.4 Redis 会话与数据库状态不同步#

会话建立后，Gateway 只读取 Redis，不再查询 user_info。

如果用户账号随后被禁用、删除或权限变化：

• 当前 Token 仍可能在 TTL 内有效；
• 除非业务主动删除会话 Key；
• 或下游每次重新校验账号状态。

当前 UserInfo 没有看到登录状态字段参与认证，仓库也没有全局强制下线链路证据。

6.5 全局异常处理#

user-service 扫描 common 包，common-service 中 GlobalExceptionHandler 会把普通 Exception 转成 Result.fail。

这意味着空请求体、passwd 为 null、selectOne 多结果等异常有机会被统一业务响应接管。

但它会调用 e.printStackTrace，且当前文档没有运行确认具体 HTTP 状态与序列化结果。

不能把“存在异常处理器”写成“所有异常场景已验证可控”。

P0：身份可信边界#

1. 公开匿名请求没有主动移除外部 userId Header，下游若信任该值可能接收伪造身份。
2. 是否能绕过 Gateway 直接访问业务服务没有部署证据。
3. authUrls.url 的真实模式未读取，不能证明所有敏感接口均受保护。
4. authUrls.url 当前只按单个字符串解析，没有多模式列表逻辑。

P1：安全与会话一致性#

1. 密码使用无盐 MD5。
2. Token 使用雪花 ID，不是密码学安全随机值。
3. IP 解析信任多个转发头，但没有可信代理名单或统一清洗证据。
4. Gateway 支持 Cookie Token，logout 只支持 Header Token。
5. 会话固定两小时且不续期。
6. 同一用户可以保留多个会话，没有全端退出。
7. Redis 会话建立后不会自动感知用户状态变化。
8. CORS 对来源、方法和 Header 较宽，同时允许凭据。

P2：工程契约与异常表达#

1. 登录 DTO 复用字段过多，且没有 @Valid 或空值校验。
2. 响应 nickName 实际取 UserInfo.name，字段语义不一致。
3. 七天 USERKEY_TIMEOUT 常量未被登录逻辑使用，容易误读。
4. UserConstants 与 RedisConst 重复声明登录常量。
5. Header 名称在多处直接写字符串，USER_LOGIN_TOKEN_HEADER 未实际复用。
6. 网关错误只写业务码，未显式设置 HTTP 401。
7. hasLogin 用 “-1” 字符串表达 IP 异常，状态类型不够明确。
8. PathPattern 每次请求重新解析，错误配置可能直接影响过滤流程。
9. 登录端与 Gateway 的 IP 提取规则不完全一致。
10. 当前没有自动化测试覆盖登录、过期、Cookie、伪造 Header 与代理场景。

第一层：先封住身份边界#

• Gateway 先移除外部 userId，再按有效会话重新写入。
• 敏感接口只允许通过 Gateway 或采用服务间认证。
• 对 authUrls 的受保护路径建立集中、可审查的配置与测试。

第二层：提升凭据安全#

• 使用高熵随机 Token，或引入明确设计的认证令牌方案。
• 用 BCrypt、Argon2id 或 PBKDF2 代替 MD5。
• 加入登录限流、失败审计和账号状态校验。
• 明确 Header 与 Cookie 的唯一契约；如果用 Cookie，需要定义安全属性与 CSRF 策略。

第三层：完善会话治理#

• 明确固定 TTL 还是滑动 TTL。
• 明确单设备、多设备、踢下线和全端退出语义。
• 建立 userId 到 Token 的反向索引或会话集合。
• 设计账号禁用后的会话失效机制。
• 设计 Redis 高可用与认证失败时的安全策略。

这些是设计讨论，不属于当前项目已实现功能。