feat(寄件): 支持管理员通过寄件码授权临时访客上传

[dawnStamp]

关联需求：#513
配套前端：vastsa/FileCodeBoxFronted#12

关闭游客上传后，管理员可发放有有效期和次数限制的寄件码。访客无需账号，复用原上传流程投递并取得普通取件码。

最终范围：只增加寄件授权

• 新寄件全部使用系统当前 file_storage、storage_path 和原 build_file_path、存储驱动。
• 删除寄件码的独立存储类型、目标目录、相关接口参数和筛选。接口拒绝客户端传入这些覆盖字段，不再单独配置账号、密钥、地址或存储规则。
• 文件大小、类型、分片、保存期限、总容量和限流继续由原系统设置及上传服务控制。
• 详情、下载、编辑、删除和过期清理复用原文件管理；只通过 FileCodes.delivery_id 关联寄件码。
• 普通上传的参数模型、分片规则、默认存储和公共驱动保持上游实现，不包含 2023 配置兼容、通用快照、通用分片修复或 Windows 检查修改。

寄件必需逻辑

• 口令、用途、授权期限、次数、启停及备注标签；不引入多用户体系。
• token 用途隔离、auth_version 撤销、刷新续期、会话归属校验与原子次数预占。
• 成功文件只存 FileCodes；预留复用 StorageReservation，移除影子文件表、独立上传接口和 HTML 后台。
• 耗尽停用并保留码，删除软删；列表 SQL 分页，口令按需读取且禁止缓存，已移除 HMAC 双存。
• 非分片寄件使用现有代理模式（含 S3）以核验真实大小，普通 S3 直传不变；旧寄件直传会话拒绝确认并安全回收。
• 配套原生界面只修改 2024，2023 源码不修改，旧寄件入口只提示切换主题。

升级与数据

• 013/014 保留历史收件关系和私有文件权限，缺少原口令的旧码停用，后台重设后再启用。
• 015 移除授权表的独立存储字段，保留 ID、计数和自增序列。
• 已上传文件和进行中的会话保留实际位置；不搬动旧文件。只有新上传跟随系统当前设置。

验证与限制

• 本次后端没有新增代码提交，当前分支为 b99e33b；同步更新配套前端与验证说明。
• 已与配套 2024 前端部署至现有实例，当前健康检查正常。前端补回寄件入口图标并修正管理页对齐。
• 此前记录的原有后端测试结果：114 passed、2 skipped、13 subtests passed；本次未重新运行后端测试。
• 此前已使用临时内存数据库验证 015 幂等迁移、历史位置保留、拒绝自定义参数、新上传跟随系统、关闭游客上传后的受控寄件，以及系统切换后旧文件下载。
• 配套前端本次架构、类型检查和构建通过；本次尚未完成浏览器视觉回归，未重复长时间上传或真实云厂商联调。
• 两个 PR 相对上游均不包含新增或修改的测试代码。
• 已包含上游 2.7.0 / NAS 更新；不引入独立存储配置，保留寄件文件后端记录及历史私有收件迁移。

既有演示截图

以下旧截图仅说明寄件流程；其中独立存储、目录配置和筛选已经移除，最终范围以上文为准。

寄件管理：筛选、标签与批量操作

创建寄件码：用途、有效期与次数

寄件码分享：口令、链接与二维码

访客凭码寄件：复用发送页面

文本寄件成功：生成独立取件码

[vercel]

Someone is attempting to deploy a commit to the vastsa's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vastsa]

先说结论：这个方向是对的，工作量也看得出来。

寄件码解决的就是 #513 那个真实痛点——公网关掉游客上传之后，临时访客还得能投递。PR 没有上账号体系，寄件 token 和 admin 隔离，次数用 SQL 原子预占，改码用 auth_version 作废旧凭证，文件还补了存储后端快照。这些点都踩在正经工程问题上，说明文档也写得很清楚，包括「没合 2.7、没做完整回归」这种限制，感谢。

配套前端：vastsa/FileCodeBoxFronted#12

不过按现状还不建议直接合，主要是架构叠了几层，后面上传/存储/清理会更难动。建议：

1. 先 rebase 当前 master（2.7 NAS）
   现在主干已经有 local_share 和本地 NAS 页。共同改动集中在 views.py、admin/services.py、路由和导航，硬合容易两边一起坏。

2. 2023 / 2024 选定一种产品语义，不要两套
   2024 Vue 复用 /share/*，会生成普通取件码；2023 兜底页走 /api/delivery/upload 且不传过期参数，结果是私有收件，访客拿不到取件码。多文件一边 ZIP 算 1 次，一边按文件计次。PR 描述里的「上传成功生成独立取件码」目前只对 2024 成立。issue 要的是丢到指定目录，需要先定一种，两套主题对齐。

3. 把寄件收薄，不要再搞第二套文件表和第三套上传
   apps.base 和 apps.delivery 已经互相依赖，upload_access / share_storage 把核心上传链路切开再缝。DeliveryFile 同时承担预占、会话、私有收件、分享关联和清理队列，真正分享还在 FileCodes，容量还要两边加。更干净的做法：DeliveryCode + FileCodes.delivery_id，上传鉴权做一层薄 Depends。
   /api/delivery/upload 这条独立上传、以及 apps/delivery/static/* 整套 HTML 管理页建议砍掉。2023 主题提示「请换 2024」即可，不必维护两套能力不一致的后台（兜底页没有批量/标签/改码/二维码，session key 也不一样）。

4. 寄件码用尽不要物理删除
   删掉之后 delivery_id 变孤儿，「按码看收件」直接 404。deleted 字段也还留着，半截软删。保留码、停用即可。

5. 补几处落地问题

   • 寄件 JWT 15 分钟且前端不续期，大文件分片会中途 401
   • list_codes 全表拉进 Python 再筛，口令原文每次都带出来，改成 SQL 分页
   • 口令 HMAC + 明文双存意义不大；能再复制可以，但列表当凭证数据保护
   • owner_id="admin" 先别铺进每条 SQL，真要接多用户再加归属
   • 上传鉴权、配额、关闭游客上传，这几条路径需要测试；现在几乎没有新测试
   • 存储快照、2023 配置字段兼容、分片大小校验，建议拆开单独合
   • 兜底 OneDrive 临时目录还留着 fr- 前缀

可以留的：token 隔离、次数预占、auth_version、存储快照、路径校验、CSP、校验接口限流、前端 publicApiClient / createDeliveryUploadClient 不和管理员会话搅在一起。这些都值得保留。

功能方向能合，这版先瘦身、对齐语义、跟上 2.7 再看。

[dawnStamp]

先说结论：这个方向是对的，工作量也看得出来。

寄件码解决的就是 #513 那个真实痛点——公网关掉游客上传之后，临时访客还得能投递。PR 没有上账号体系，寄件 token 和 admin 隔离，次数用 SQL 原子预占，改码用 auth_version 作废旧凭证，文件还补了存储后端快照。这些点都踩在正经工程问题上，说明文档也写得很清楚，包括「没合 2.7、没做完整回归」这种限制，感谢。

配套前端：vastsa/FileCodeBoxFronted#12

不过按现状还不建议直接合，主要是架构叠了几层，后面上传/存储/清理会更难动。建议：

1. 先 rebase 当前 master（2.7 NAS）
   现在主干已经有 local_share 和本地 NAS 页。共同改动集中在 views.py、admin/services.py、路由和导航，硬合容易两边一起坏。

2. 2023 / 2024 选定一种产品语义，不要两套
   2024 Vue 复用 /share/*，会生成普通取件码；2023 兜底页走 /api/delivery/upload 且不传过期参数，结果是私有收件，访客拿不到取件码。多文件一边 ZIP 算 1 次，一边按文件计次。PR 描述里的「上传成功生成独立取件码」目前只对 2024 成立。issue 要的是丢到指定目录，需要先定一种，两套主题对齐。

3. 把寄件收薄，不要再搞第二套文件表和第三套上传
   apps.base 和 apps.delivery 已经互相依赖，upload_access / share_storage 把核心上传链路切开再缝。DeliveryFile 同时承担预占、会话、私有收件、分享关联和清理队列，真正分享还在 FileCodes，容量还要两边加。更干净的做法：DeliveryCode + FileCodes.delivery_id，上传鉴权做一层薄 Depends。
   /api/delivery/upload 这条独立上传、以及 apps/delivery/static/* 整套 HTML 管理页建议砍掉。2023 主题提示「请换 2024」即可，不必维护两套能力不一致的后台（兜底页没有批量/标签/改码/二维码，session key 也不一样）。

4. 寄件码用尽不要物理删除
   删掉之后 delivery_id 变孤儿，「按码看收件」直接 404。deleted 字段也还留着，半截软删。保留码、停用即可。

5. 补几处落地问题

   • 寄件 JWT 15 分钟且前端不续期，大文件分片会中途 401
   • list_codes 全表拉进 Python 再筛，口令原文每次都带出来，改成 SQL 分页
   • 口令 HMAC + 明文双存意义不大；能再复制可以，但列表当凭证数据保护
   • owner_id="admin" 先别铺进每条 SQL，真要接多用户再加归属
   • 上传鉴权、配额、关闭游客上传，这几条路径需要测试；现在几乎没有新测试
   • 存储快照、2023 配置字段兼容、分片大小校验，建议拆开单独合
   • 兜底 OneDrive 临时目录还留着 fr- 前缀

可以留的：token 隔离、次数预占、auth_version、存储快照、路径校验、CSP、校验接口限流、前端 publicApiClient / createDeliveryUploadClient 不和管理员会话搅在一起。这些都值得保留。

功能方向能合，这版先瘦身、对齐语义、跟上 2.7 再看。

好的，我去优化上传一下，确实有些考虑的不周全。

[Marrrrrrrrry]

先说结论：这个方向是对的，工作量也看得出来。

寄件码解决的就是 #513 那个真实痛点——公网关掉游客上传之后，临时访客还得能投递。PR 没有上账号体系，寄件 token 和 admin 隔离，次数用 SQL 原子预占，改码用 auth_version 作废旧凭证，文件还补了存储后端快照。这些点都踩在正经工程问题上，说明文档也写得很清楚，包括「没合 2.7、没做完整回归」这种限制，感谢。

配套前端：vastsa/FileCodeBoxFronted#12

不过按现状还不建议直接合，主要是架构叠了几层，后面上传/存储/清理会更难动。建议：

1. **先 rebase 当前 master（2.7 NAS）**
   现在主干已经有 `local_share` 和本地 NAS 页。共同改动集中在 `views.py`、`admin/services.py`、路由和导航，硬合容易两边一起坏。

2. **2023 / 2024 选定一种产品语义，不要两套**
   2024 Vue 复用 `/share/*`，会生成普通取件码；2023 兜底页走 `/api/delivery/upload` 且不传过期参数，结果是私有收件，访客拿不到取件码。多文件一边 ZIP 算 1 次，一边按文件计次。PR 描述里的「上传成功生成独立取件码」目前只对 2024 成立。issue 要的是丢到指定目录，需要先定一种，两套主题对齐。

3. **把寄件收薄，不要再搞第二套文件表和第三套上传**
   `apps.base` 和 `apps.delivery` 已经互相依赖，`upload_access` / `share_storage` 把核心上传链路切开再缝。`DeliveryFile` 同时承担预占、会话、私有收件、分享关联和清理队列，真正分享还在 `FileCodes`，容量还要两边加。更干净的做法：`DeliveryCode` + `FileCodes.delivery_id`，上传鉴权做一层薄 Depends。
   `/api/delivery/upload` 这条独立上传、以及 `apps/delivery/static/*` 整套 HTML 管理页建议砍掉。2023 主题提示「请换 2024」即可，不必维护两套能力不一致的后台（兜底页没有批量/标签/改码/二维码，session key 也不一样）。

4. **寄件码用尽不要物理删除**
   删掉之后 `delivery_id` 变孤儿，「按码看收件」直接 404。`deleted` 字段也还留着，半截软删。保留码、停用即可。

5. **补几处落地问题**
   
   * 寄件 JWT 15 分钟且前端不续期，大文件分片会中途 401
   * `list_codes` 全表拉进 Python 再筛，口令原文每次都带出来，改成 SQL 分页
   * 口令 HMAC + 明文双存意义不大；能再复制可以，但列表当凭证数据保护
   * `owner_id="admin"` 先别铺进每条 SQL，真要接多用户再加归属
   * 上传鉴权、配额、关闭游客上传，这几条路径需要测试；现在几乎没有新测试
   * 存储快照、2023 配置字段兼容、分片大小校验，建议拆开单独合
   * 兜底 OneDrive 临时目录还留着 `fr-` 前缀

可以留的：token 隔离、次数预占、auth_version、存储快照、路径校验、CSP、校验接口限流、前端 publicApiClient / createDeliveryUploadClient 不和管理员会话搅在一起。这些都值得保留。

功能方向能合，这版先瘦身、对齐语义、跟上 2.7 再看。

这个我正在做 我想的是把项目健壮性收尾结束就开始（这两周我不是在补测试和检查项目问题吗） 我做的不是这种一个码有限次投递 我定位是收件箱 例如12345 56789这种多个id对应不同收件盒子 然后这个模式跑通了 我再加这个收件箱的生命周期管理 我觉得我这种还是很完善的 然后还能复用项目已有组建（我拆分耦合模块就是为了尽可能复用公共逻辑）

[Marrrrrrrrry]

已有组件（输入法候选词不精确）

[autumn231]

我认为还是不要使用账号体系（我有一种对账号体系天生的反感，不知道大佬们有没有），就是临时下发密钥，并且记录文件上传是凭哪个密钥和从哪个IP上传的，这样我认为会更好一点，并且增加一个拉黑上传IP或者管理某个密钥的功能，可以新增一个密钥库，该密钥库可以看见，新增，和管理已增加密钥的权限和给该密钥备注的功能，已经使用该密钥的IP，例如使用该密钥的IP为5个，当达到上限后，不能再使用其他的IP和该密钥上传文件。并且我认为密钥不要类似于账号登录一样保存在浏览器里面，可能我的语言表达不是很准确，但是或许能提供一些想法。我的理念核心是增强管理员端对该体系的掌控能力，其他使用者只需要密钥➕不乱换上传IP就可以正常使用。这样可以实现半公开的使用范围。