Archived
snowy-yang
1973d6a0e8
为什么：签发侧 Cookie 的 max_age 是 7 天，但那只是**浏览器**行为——被保存、 复制或从日志里捞出来的旧 Cookie 仍带着有效签名，而解析侧 loads 从不校验签发 时间（max_age=None），等于「登录态永不过期」。登出/顶号靠递增 login_seq 兜底， 但拿不到库的一方（如泄露的 Cookie）无从失效。 改法： - core/session.py 新增 COOKIE_NAME / SESSION_MAX_AGE，作为会话名与有效期的 唯一来源。此前 'session' 在 web/deps、web/routers/auth、web/routers/register 各写一遍，7 天在两处各写一遍——三处同名常量各改各的，正是漂移温床。 - web/deps._parse_cookie 传入 max_age=SESSION_MAX_AGE，过期判定落在服务端。 - 两个签发侧改引用共享常量（保留模块级别名，对外名字不变）。 - loads() 的签名与语义**不变**（max_age=None 仍不校验）：它是通用工具，策略 属于调用点，这样 test_session 里「None 接受旧时间戳」的语义继续成立。 行为变更（本轮唯一一处）：签发时间超过 7 天的会话 Cookie 现在按未登录处理。 正常浏览器用户无感——浏览器本来就按 max_age 丢弃它；受影响的是手工保存、 跨 7 天复用的旧 Cookie，正是要堵的那类。 验证： - 新增 tests/test_deps.py::test_expired_cookie_rejected：用 monkeypatch.context() 把时钟拨回 SESSION_MAX_AGE 之前签发（itsdangerous 时间戳取自 dumps 时刻）， 再以当前时间解析 → 必须拒绝；同时断言有效期内不受影响。用 context 而非 undo()，后者会连带撤销 site fixture 的设置。 - 变异验证：把 max_age 参数摘掉后**恰好**该用例变红、其余 10 例全绿——证明测试 精确盯着这一处，不是碰巧通过。 - ruff 全过 · pyright 0/0 · pytest 214 passed（213→214）。golden 快照与 test_download_billing（真实登录拿 Cookie 打 API）均通过，端到端链路未受影响。