# 工作日结_2026-09-16 ## 一、今天做了什么 ### 1. 环境启动 - 11:12 用 `start-dev.ps1` 启动前后端(启动前 8090/8080 均空闲)。 - 就绪标志:后端 `Tomcat started on port(s): 8090` / `Started TrafficAuditApplication`;前端 `Compiled successfully` / `App running at:`。 ### 2. 修复「用局域网 IP 打开页面后登录失败」 - **用户反馈**:用 `http://192.168.177.26:8080/` 登录提示「网络错误,登录失败」,而 `http://localhost:8080/` 正常。 - **排查路径**:curl 直发同一 URL 的 POST `/api/auth/login` 正常返回(说明后端与代理都通)→ 用应用内浏览器在 LAN 地址复现(确实提示「网络错误,登录失败」)→ 对比出差异只在 `Origin` 头 → curl 补 `Origin: http://192.168.177.26:8080` 得到 `403 Invalid CORS request`,根因落地。 - **根因**:浏览器 POST/PUT/DELETE 必带 `Origin`(GET 不带);9-14 跨域收紧后白名单只列了 `localhost:8080 / 127.0.0.1:8080`,经 dev-server 代理转发过来的 `Origin: http://192.168.177.26:8080` 命中不了,被 `CorsFilter` 403 拦掉。页面本身和 `GET /api/auth/captcha-config` 不带 `Origin` 所以正常,表现为"页面能开、一登录就网络错误"。 - **顺带发现**:打包部署(前端内嵌、用 `http://<部署机IP>:8090` 访问)时 POST 同样带 `Origin: http://:8090`,也会被 403 挡住登录——属于同类隐患,本次一并解决。 - **改动(2 文件)**:`CorsConfig.java` 由 `setAllowedOrigins` 改为 `setAllowedOriginPatterns`,默认放行 `http://localhost:*`、`http://127.0.0.1:*`、`http://192.168.*:*`、`http://10.*:*`、`http://172.*:*`;`application.yml` 的 `app.cors.allowed-origins` 同步并补注释。白名单校验机制与 `allowCredentials=false` 均未放松。 - **验证**:按 PID 精确停旧后端链(`cmd 3608 → java(maven) 23704 → java(app) 12636`)后重启;应用内浏览器在 LAN 地址实登成功进入 `#/dashboard`;白名单负向用例(`http://evil.example.com`)仍 403。详见《功能测试报告_局域网IP访问登录CORS修复_2026-09-16.md》。 ## 二、测试结果摘要 - CORS 修复 12 条用例全通过:正向(LAN 来源、同源 8090 来源、内网网段来源、带令牌业务接口、预检 OPTIONS)、负向(非法来源 403)、回归(localhost 来源、无 Origin 头)。 - 真实浏览器端到端:`http://192.168.177.26:8080/#/login` 输入 `admin/123456` → 提示「登录成功」→ 跳转工作台,顶部显示 admin。 - 今日无导入/数据库写入操作,未做入库抽查(改动只涉及跨域校验,不触碰数据链路)。 ## 三、遗留问题与待办 1. **改用域名访问时需补白名单**:`app.cors.allowed-origins` 默认只覆盖本机 + 内网网段,若将来用域名或公网 IP 访问,需把该来源(含端口)追加进去(yml 注释已写明)。 2. `Login.vue` 把所有失败都提示为「网络错误,登录失败」,403/500 这类有响应的错误也被归到"网络",排查易误导;建议后续按状态码细分提示(未做,等用户确认)。 3. 9-15 遗留继续挂账:AI 外发脱敏补齐(system prompt 企业名/解释原文未脱敏)、保密数据部署路线确认、4 张明细报表模板扩列、审核比对基准缺失保护、`sys_role` 权限落地、3D 验证码生产开启、`backend.log` 历史明文清理。 4. 仓库根目录仍有大量未跟踪临时文件(`_*.py`/`_*.sql`/`_*.ps1` 等)未被 `.gitignore` 覆盖,清理前需用户确认。 5. 公司 gitea(`61.183.254.94:3000`)推送仍受本机凭据问题影响;今日按第 3 条工作规范尝试 fetch/合并/推送,结果见下条 git 记录。 ## 四、明天计划 1. 与用户确认域名/其他访问方式是否需要一并加白名单,并确认 `Login.vue` 错误提示细分方案是否实施。 2. 推进 AI 外发脱敏补齐(约 20 行改动),完成后写《功能测试报告》,沿用"假 DeepSeek 服务抓包"做报文级验证。 3. 继续推进报表模板扩列 / 审核基准保护等挂账项。 ## 五、git 记录 - 本次改动:`CorsConfig.java`、`application.yml`、本报告与日本日结。 - 流程:先写《功能测试报告》与本《工作日结》,再 `git fetch origin`(gitee,`master`)与 `git fetch gitea`(公司,`main`)对比合并,确认无冲突后提交并推送。