 Lu Ke
|
50498bbe07
|
Windows 便携包：只收 git 跟踪的文件、生产依赖、钉死的 Node 版本与许可证 (#30)
|
2026-10-04 14:20:11 +08:00 |
|
|
Lu Ke
|
8b10625d3c
|
打开浏览器改用 explorer.exe（shell 关联），找不到时才用 rundll32 (#29)
Windows 上先同步判断 explorer.exe 是否存在：存在就用 explorer.exe <url>，由已登录、未提权的 shell 按默认浏览器关联打开，从管理员控制台启动时浏览器不会跟着提权（Edge 不再弹「现有实例正在以提升的权限运行」）；找不到 explorer.exe 才退回 rundll32 url.dll,FileProtocolHandler。不经过 cmd，URL 里的 & 不会被截断。macOS / Linux 不变。
打开浏览器的实现集中到 scripts/open-browser.mjs；scripts/launch.mjs 加 isMain() 守卫（与 tools/setup.mjs、tools/doctor.mjs 一致），被 import 时不会启动服务器。测试：test/open-browser.test.js。
|
2026-10-03 23:05:06 +08:00 |
|
|
kanomahoro1224
|
cfa51e5f1b
|
按 review 意见：/media/ 的路径与扩展名列表提到 shared/ 共用
- server/index.js 开头的路由说明补上 /media/
- AUDIO_EXTS 原先客户端（public/js/media.js）与服务端各一份，只改一边就会悄悄漂移：
现在两边都从 shared/media.js 取；服务端那份不再 export
- isMediaUrl 只有测试在用，删掉（新增 shared/media.js，测试改从那里取前缀/扩展名）
- 顺手做了 review 里「可选」的那点：有些静态托管对不存在的路径回 200 + index.html，
这种响应解码会静默失败，所以除了 404，声明了非 audio/* 类型的响应也回退到原地址
（完全没声明 content-type 的不算错——没有证据表明它不是音频）
|
2026-10-03 22:33:20 +08:00 |
|
|
kanomahoro1224
|
a069be4538
|
音频改走无扩展名的 /media 路由：IDM / 迅雷 这类下载管理器不再弹「下载文件信息」
玩家那边遇到的是：游戏放着 BGM，突然弹出下载管理器的「下载文件信息」框，有时还会把整条
音轨抢去下载。原因是这些工具会嗅探以媒体扩展名结尾的 XHR/fetch。改成客户端统一请求不带
扩展名的 `/media/<原路径去掉 .mp3>`，服务端再解析回 `public/assets/audio/…`。
- `public/js/media.js`：`mediaUrl()` 把 `/assets/audio/**.mp3` 换算成 `/media/**`，只处理同源、
且扩展名在名单内的地址；跨域、目录、`..`、点开头、不认识的扩展名一律原样返回。
- `server/index.js`：新增 `/media/` 路由。按 `AUDIO_EXTS` 顺序找 `.mp3/.m4a/.aac/.ogg/.oga/.opus/.wav`，
显式写了扩展名的以它为准；Range/ETag/Content-Type/缓存策略都复用 `serveFile`，所以和直接请求
`/assets/audio/…` 行为一致（一天缓存、支持 Range）。
- 直接请求 `/assets/audio/…` 仍然可用 —— 这是给不支持 `/media/` 的纯静态托管留的退路，客户端
在 `/media/` 404 时才回退到原地址。
安全：`/media/` 的路径只接受正常片段，`..`/`.` 直接 403，点开头或点结尾的片段 404，解析出的
绝对路径必须落在 `public/assets/audio` 之内，且只允许上面那几个音频扩展名 —— 不会变成任意文件读取。
测试：
- `test/media-url.test.js`：`mediaUrl()` 的换算与各种「别动它」的边界。
- `test/lobby.test.js`：真实服务器上的 `/media` 路由（正常解析、显式扩展名优先、Range、HEAD、
目录与穿越请求被拒、客户端回退用到的 `/media/bgm.mp3` 仍 200）。
- `test/ui/audio.test.js`：音频管理器现在先请求无扩展名地址，404 才回退原地址；断言跟着
`mediaUrl()` 换算后再比对（原先拿 manifest 原地址比对，等于断言一个客户端永不请求的 URL）。
|
2026-10-03 22:33:19 +08:00 |
|
|
kanomahoro1224
|
9f9207a66e
|
启动器「发给朋友」不再把代理 TUN 当公网 IP；删掉永不生效的 ^tun\d
198.18.0.0/15 是 RFC 2544 的基准测试段，Clash / Mihomo 这类代理软件拿它当本地 TUN 的
fake-ip 池 —— 那是本机自己的地址，冒充「公网 IP」发给朋友只会让人连不上。同时按网卡名
补上 Radmin VPN / Hamachi：它们是点对点地址，正是同组好友互连要用的，仍留在 vpn 一类。
另外删掉 VIRTUAL_IF 里的 `^tun\d`：分类顺序是 VPN_IF → VIRTUAL_IF，而 VPN_IF 里的
`tun\d` 是子串匹配，凡能被 `^tun\d` 命中的名字都已经被它命中，这条永远轮不到。同一个
判断写在两处、其中一处是死代码，只会让后来者以为顺序无所谓（review 里就是这么指出的）。
测试从 test/windows-bundle.test.js 移到独立的 test/doctor.test.js —— 这本来就是
tools/doctor.mjs 的纯函数，不该挂在打包测试里。另补两条钉住分类顺序的用例：一条防止
`^tun\d` 被抄回 VIRTUAL_IF，一条记录 macOS 的 utunN 因 `tun\d` 子串匹配而归 vpn 的现状
（那是仓库原有行为，本次未改；把它写下来，免得有人误以为 VIRTUAL_IF 里的 `utun` 在起作用）。
|
2026-10-03 15:41:57 +08:00 |
|