|
|
fe5ddf274b
|
feat(deploy): 首装脚本补 TLS 自检（跳转端口 302 / HTTP2 协商 / 证书可读）
TLS 是有证书用户的主路径，之前只在生产手工验过、脚本没覆盖。补上后
NAVI_TLS=1 的首装会自己验证：http 跳转端口是否 302 到 https、入口能否
协商 HTTP/2（对应曾踩过的 listen … ssl http2 写法）、证书是否能读出主题。
|
2026-09-12 09:45:13 +08:00 |
|
|
|
965c9cb41a
|
fix(deploy): code_of 定义提到等待循环之前（自检退出码 127）
第二次练兵：路由表路径修复生效（apply routes: 2），但因等待监听的循环
调用了尚未定义的 code_of，脚本以 127 退出。把函数定义移到首次调用之前。
|
2026-09-12 09:41:01 +08:00 |
|
|
|
158217103d
|
fix(deploy): 首装路由表路径写错（静默零路由）+ apply 空表安全阀
真实练兵（干净数据目录跑 install-host.sh）抓到：
1. 路由表源文件被写到 <数据卷>/gateway/gateway.yml，容器实际读取 <数据卷>/gateway.yml
→ apply 报 routes: 0，用户自备/生成的初始路由被静默忽略
2. 自检在 apply 后立即探测，nginx 还没 reload 完 → 误判连接失败；
code_of 失败时重复输出 000
3. 缺安全阀：路由表为空时 apply 会照常生成零路由配置并覆盖，
等于静默清空入口路由表
修复：
- install-host.sh 改写 <数据卷>/gateway.yml（并注释说明两个目录的区别）
- 自检前轮询等待入口监听就绪（最多 10s），code_of 只在成功时输出状态码
- handleGatewayApply 增加安全阀：路由表为空但现有配置含 server_name → 400 拒绝覆盖
- 新增测试 TestApplyRefusesEmptyRoutesOverExisting
|
2026-09-12 09:40:36 +08:00 |
|
|
|
c0cbdb5efc
|
feat(deploy): 补首装路径，使他人/AI 可照教程从零部署
审计发现 5 处断点（3 处硬阻断）：
1. Dockerfile 的 HTTP_PROXY/HTTPS_PROXY 默认指向内网代理 → 他人构建必失败
2. zd-host.sh 是升级脚本（要求已存在 host 模式 navi 容器）→ 新机器第一句过不去
3. docker-compose.yml 是桥接+端口映射，与'统一入口 host 模式'口径冲突
4. 证书文件名约定未文档化（实际来自 gateway.yml 的 certFile/keyFile）
5. 环境变量表不完整、缺 sshpass 依赖说明
本次：
- Dockerfile：代理默认置空，需要时 --build-arg 传入
- deploy/install-host.sh（新）：干净机器首次安装，6 步并在任一步失败即停，
含端口独占检查、证书检查、初始 gateway.yml 生成、apply、四项自检，
令牌可自动生成并只打印一次；已存在 navi 容器时拒绝执行（引导去 zd-host.sh）
- docker-compose.yml：标注为试用形态，指向 install-host.sh
- README：新增「从零部署（干净机器）」——两条路径分工表、前置条件表、
完整环境变量表、证书与初始网关配置说明、装完自检命令；自定义文件表登记新脚本
另修：脚本自检原用 /.navi-ping（该路径已按用户要求删除），改用 /conf.yml。
|
2026-09-12 09:37:45 +08:00 |
|
|
|
13ab2336c6
|
fix(deploy): host 部署后自动重新生成一次网关配置
事故：门户首页改为由 admin-server 渲染（/portal-page）后，镜像里的门户模板带
HTML 占位符，而线上 gateway.conf 仍是上一版生成的（未引用渲染器），导致
门户页占位符裸露、标题为空。
在 zd-host.sh 的入口自检之后加入 apply 步骤（用同一份 env 里的 admin token），
失败即中止并回滚，避免镜像已更新但配置没跟上这类静默不一致。
|
2026-09-12 09:16:38 +08:00 |
|
|
|
352aa570ec
|
chore: 验收脚本入库（矩阵/工作空间/滚动）+ 修正脱敏自检命令
- deploy/verify-matrix.js：6 尺寸 × 3 视图 × 深浅色矩阵，断言纵向滚动（仅
minimal/workspace）、文字亮度阈值、深色是否生效、零运行时异常
- deploy/verify-workspace.js：触发 workspace blocked 态，读弹窗卡片 computed style
- deploy/verify-scroll.js：多视口滚动复现（含 900x520 这类矮窗口）
三者只从环境变量 PORTAL_COOKIE 取会话，无任何硬编码凭据
- README 自检命令改为排除占位符（<...>、${VAR:-}、change-me），避免误报
- 自定义文件表登记上述脚本
|
2026-09-12 08:55:04 +08:00 |
|
|
|
a78c5180ca
|
fix(deploy): host 模式远端显式接收 VER
首次 host 部署在停旧容器后因远端 VER 未定义触发 unbound variable 而失败
（当时旧容器仅被改名未恢复，已手工恢复）。此处只补参数传递，不改动
heredoc 结构与回滚顺序。
|
2026-09-12 07:36:20 +08:00 |
|
|
|
b1e4367937
|
fix(theme): 深色改为整套主题变量覆盖，不再改写 data-theme
用户反馈"深色区域有的方形、有的根本没变深"。根因有两层，都是我的做法错了：
1. navi.js 会把 <html data-theme> 改成 "dark"。Dashy 的配色变量是按主题名
作用域输出的（本站主题 jianf-glass），改掉它 → 整套主题变量失配 →
有的区域完全没变深。
2. navi.css 之前只覆盖"页面底色 + 我们自己的悬浮件"，Dashy 自己的卡片/侧栏/
头部仍走原主题 → 与深底色拼在一起，就成了直角圆角混杂。
改法：
- navi.js 只切 <html class="navi-dark">（并设 color-scheme），绝不碰 data-theme
- navi.css 用 html.navi-dark 一次性覆盖 jianf-glass 的全部配色变量（47 个：
背景/卡片分组/条目文字/侧栏/头部导航/搜索框/设置面板/弹层/滚动条/语义色），
Dashy 自身界面随之整体一致变深；形状由元素自身样式决定，不再混杂
- 选择器 html.navi-dark 特异度(0,1,1) 高于 [data-theme=…](0,1,0)，与注入顺序无关
需要目视确认配色层次（变量值只能看着调）。
|
2026-09-11 23:31:27 +08:00 |
|
|
|
53beff646a
|
feat(admin): 现有配置导入 + 添加表单补齐认证/导航开关 + 统一登录账号设置 + 设置分组
针对反馈的五个问题：
1. 后台"没有映射"：新增 /admin/api/gateway/import 与界面「从现有 nginx 配置导入」，
把老统一入口的 nginx 配置贴进来即可解析出全部「域名 → 后端」初稿
（含 requireLogin / 免认证路径 / SSE 流式 / 备案注入 / 自签证书 / auth 与 portal 类型）。
解析只读不落盘，确认后才保存；导入默认不接管导航，避免一导入就改掉手工导航。
2. 添加转发时没有导航选项：添加表单补齐「同时加入 Dashy 导航 / 分组 / 名称 / 描述 /
图标 / 自动抓取」。
3. 添加转发时没有 portal 保护选项：添加表单补齐「启用 portal 统一登录保护」，
并补上 WebSocket 透传与上传上限。
4. 设置里无法配置 portal 账号：新增统一登录账号卡片，账号存数据卷
（portal-auth.json，只存加盐哈希），优先级 数据卷 > 环境变量，
改完立即生效、无需重新部署；会话校验按当前用户名，改账号后旧会话失效。
5. 设置项太乱：按用途分组（站点与外观 / 导航内容 / 历史记录 / 转发与统一登录 / 高级），
外观卡片并入站点组。
另修两个本轮引入的缺陷：
- 容器假 unhealthy：内部端口改 18080 后，基础镜像的 HEALTHCHECK 仍指向 8080；
部署脚本生成的 Dockerfile 现在显式覆盖为 :18080/healthz。
- kind=auth 不依赖 portal-auth 容器，指向内置登录服务；避免生成空 proxy_pass。
测试：nginx 配置解析（含兜底段忽略、多域名段、类型判定、默认不接管导航）、
垃圾输入报错、账号存储（不明文、可校验、改名后旧口令失效）、auth 类型生成。
|
2026-09-11 22:00:09 +08:00 |
|
|
|
994d93cc98
|
feat(gateway): 一体化统一入口——路由与 Dashy 导航同一份数据、内置登录、原自定义错误页
目标：一个 HomeDash 容器取代 navi + portal-nginx + portal-auth。
- Route 扩展为"反代 + 导航"一条记录：kind(proxy/portal/auth)、streaming、
insecureTls、bypassPaths、injectBeian，以及 navEnabled/navSection/navName/
navDescription/navUrl/navIcon/navAutoIcon
- 保存路由时**同时**写 gateway.yml 与 conf.yml 的导航项（gateway_nav.go）：
同 host 接管而不是重复、未勾选导航的会被清理、无关手工项与系统「历史访问」分组
一律不动；两步任一步失败都回滚（避免后台显示与导航页各说各话）
- 未知域名与上游故障改用**内置自定义 404/500 页面**（portal/ 目录），
不再是一行纯文本；HTTP→HTTPS 跳转段用 RedirectPort 复刻原 3081 设计
- 内置统一登录（auth.go）：HMAC 签名 cookie、恒定时间比较、登录跳转白名单校验，
portal-auth 容器可以退场
- 自动抓图标对托管导航项同样生效（history-server 识别 naviGatewayAutoIcon）
- 后台卡片补齐"加入导航/分组/名称/描述/图标/自动抓图标/服务类型"字段
- 内部入口端口 8080 → 18080：为一体化 host 模式让开宿主机 blog(:8080)
- 修掉上一轮编辑写坏的 deploy/zd.sh 一行（会让脚本直接失败）
测试：新增自定义错误页、portal 类型、导航字段校验、导航同步（接管/清理/保留）、
分组不存在必须报错等用例；admin-server 与 history-server 全绿。
|
2026-09-11 21:27:40 +08:00 |
|
|
|
507632609d
|
fix(deploy): 历史条数守卫改为与切换前对比，而不是写死条数
写死 4 条会把「用户自己在后台删了几条记录」误判成部署失败（本轮实际发生），
同时又发现不了真正的丢数据。改成切换前读一次旧容器的条数，切换后要求
新容器 >= 旧值：同步接口只累加不删除，所以变小即为异常。
|
2026-09-11 20:30:52 +08:00 |
|
|
|
a6b5513f88
|
docs+chore: 部署脚本入库、README 补零停机部署与部署物料清单
仓库此前缺少部署脚本，只能靠临时文件操作，新人无法复现。补齐：
- deploy/zd.sh：零停机部署（新容器先在对侧端口验证到底，含 /search 预热
SearXNG；再同 inode 覆写门户上游 + nginx -t + reload；切后哨兵"不得为 502"；
失败自动回滚，旧容器保留为回滚点）。可用环境变量覆盖主机/路径/镜像。
- deploy/verify-ui.js：部署后浏览器验收（渲染开销、后台窄屏、收边两段式、
被拒内嵌弹层、分组增删改与「历史访问」保护）。任一运行时异常即判失败。
README 新增：
- 「零停机部署」含**单文件 bind mount 不能用 sed -i** 的坑（换 inode → 容器读到
旧值 → 全站 502，本项目真实踩过）与正确顺序（同 inode 覆写 → 断言容器看到 →
nginx -t → reload）
- 「部署需要的全部自定义文件」清单表
- 「管理后台」补分组自由增删、历史分组保护、完整 API 表
- 「工作空间视图」补可内嵌性三态探测（转发 Cookie、WAF 403 误判）、被拒弹层、
悬浮控件收边与"第一次交互只滑出"
|
2026-09-11 20:13:44 +08:00 |
|
