laoyang/FamilyBook
1
0
Fork 0
Code Issues 29 Pull Requests Actions Packages Projects Releases Wiki Activity
164 Commits 1 Branch 0 Tags
50286e5327bdbb3a39d5a1391d9842f3c1fd6d3f
Commit Graph
5 Commits
Author SHA1 Message Date
laoyang fec898c18d v46：CardDAV 通讯录 —— 显示名用称呼 + 档案进备注 + 单位进工作地址 + 头像内嵌 
用户 2026-10-13 四条（含一条安全确认）：

① 【安全确认，无需改代码】「加日历时要输 Token，加通讯录时不再要了，这权限不对吧？」
   实测线上：匿名 PROPFIND/GET /carddav/ → 401；错口令 → 401；正确 DAV 口令 → 207。
   **CardDAV 与 CalDAV 共用同一把 DAV 口令、且都强制鉴权**，不存在绕过。
   用户没被再问一次是因为 Thunderbird 会复用**同一主机**上已存的 Basic 凭据
   （realm 都是 "FamilyBook DAV"）—— 那是客户端的设计，不是服务端的洞。

② 【头像】「通讯录同步都没有头像，但咱们是有头像的……清晰度调到最高」
   · 新增 PHOTO 行：`PHOTO;ENCODING=b;TYPE=JPEG:<base64>`（vCard 3.0 内嵌，原字节不二次压缩）
   · 库里那张已是上传时重采样的 512×512 JPEG q88 ⇒ 清晰度已到顶；
     仅当 >300KB 时才等比缩到 384（shrinkImage）
   · 🔴 字节**必须走 Storage::read**：线上 storage_driver=oss，
     实测 20 个有头像的人里**只有 5 个在本地 uploads/、15 个只在 OSS**
     ⇒ 只读本地会静默漏掉 15 个人的头像。已实测 photoBytes 取到 20/20。
   ⚠️ 已实测告知：**Thunderbird 不会显示**这张照片 —— TB 157 的
      `modules/VCardUtils.sys.mjs` typeMap 里**没有 photo**；
      但 iOS 通讯录 / DAVx⁵ / 群晖 Contacts 支持，所以照写。

③ 【显示名 + 备注】「名字用我们给他起的称呼，把原名/关系/我写的备注都放进备注」
   · `FN` = 称呼（`nicknames`，viewer 维度；没起过则回退真名）
   · `N`   = 真名（iOS 靠它排序/搜索；缺了会按"无名"排）
   · `NICKNAME` 只在"显示名≠小名"时写（同步时 FN 已是小名 ⇒ 不重复；
     备份导出时 FN=真名 ⇒ NICKNAME 保住小名，往返不丢）
   · `NOTE` 富化：原名 / 与我的关系 / **我写的私人备注**（person_notes）/
     自我介绍 / 现单位 / 现职称 / 工作经历（多段，从早到晚，末段标"现在"）

④ 【单位 + 工作地址】「职称和单位只写现在的；工作经历也放备注；单位放到工作地址栏」
   · ORG/TITLE 只写当前（persons.org/title 本就是 PersonJob::syncCurrent 的当前快照）
   · 新增 `ADR;TYPE=WORK:;;<当前单位>;;;;`（用户明确"就是工作单位，不需要单位地址"；
     该栏在 TB 的 typeMap 里有 `adr.work`，是它通讯录**会显示**的字段）

🔴 一条关键设计约束：**富化只在"同步模式"下做**（`$display !== $real`）。
   备份导出那条路径（显示名=真名）NOTE 只放原有备注、不写 ADR;TYPE=WORK ——
   否则既有 e2e 的**往返一致**守卫会红：导出的富化备注会被当备注再存一份，
   越导越多且不可逆。第一版只给"自我介绍"打了门禁、其余照拼，往返断言当场变红。

🔴 配套改 `ContactImport`：姓名改成 **N（真名）只要非空就覆盖 FN（显示名）**
   （原来是 FN 优先）。否则我们的卡（FN=称呼、N=真名）导回来会
   **让一个人被自己的称呼改掉名字**。安全性已逐条确认：我们自己的卡字段顺序固定、
   标准客户端只写 FN、老手机只写 N —— 三种情况结果都正确。

验证（新增两个套件）：
  · `_fb_v46_carddav.py`（29 条）：造"信息最全"夹具（称呼/私人备注/自我介绍/当前单位职称/
    三段经历/真 JPEG 头像）→ 真发 CardDAV 请求拉回逐字段断言 + 鉴权四态。**29/0**
  · `_b46_carddav_falsify.py`（9 个注入）：FN 改回真名 / 备注少项 / 不写 PHOTO /
    头像数据源切断 / 放行匿名 —— **9/9 全抓住**
  · `_fb_b22_vcf_spec.php`（vCard 规格 + 往返一致）：**40/0**
  · 全量 e2e **1510/0**；TB 探针 44/0；DAV 诊断 28/0；v45 双向写 24/0
  · 全流水线 **PUSH_RC=0**（含部署静态断言"第46批形态"）
  · **线上终验 13/0**：真公网拉 801 张卡；FN='胖胖' / N='杨永全' /
    NOTE='原名：杨永全；与我的关系：丈夫；现单位：中国海洋大学；现职称：副教授；
    工作经历：中国海洋大学（副教授）'；20 张卡带 PHOTO 且 base64 可解回真图；
    匿名/错口令 401

顺带修掉一个**探针自身的偶发假红**（v45c 引入的，与 v46 无关）：
  `_fb_b44_ui.py` 的 3b 用"浏览器此刻分钟"当基准，而页面是服务端在 10:07:59 渲染的
  ⇒ 时钟漂移 1 分钟；跨度 3 小时时 1 分钟=0.556% 又超 0.3% 容差 ⇒ 两条判据同时违反。
  改成用**服务端自报的 data-now-min 反算它自己该放的位置**（两端同源、零容差、不受漂移影响）；
  `_b44_falsify.py` 的关键词同步更新。v44 反向验证恢复"基线全绿 + 19/19"。
 2026-10-13 11:53:58 +08:00
laoyang feff31baad v45b 修复：Thunderbird「找不到日历/联系人」的真根因 
用户 2026-10-12 晚：「dav 还是不行，thunderbird 提示找不到日历，联系人也没有。」

真根因（一个由两半无缝衔接构成的 bug）：
  TB 添加账号 → GET /.well-known/caldav → 我们 301 到 /dav/
              → TB **跟随这个 GET 跳转** → GET /dav/
              → 我们回 **404「没有这本日历」**
              → TB 判定"这里没有日历" ⇒ 报「找不到日历」。
  CardDAV 完全同型（/.well-known/carddav → GET /carddav/ → 404）
  ⇒ 所以日历和联系人是**同一个 bug**。

修法（对齐参照 DAViCal 的状态码语义）：
  · GET 打到 home 容器（bookId=0）→ **405**（原来 404）
    404 = "资源不存在" ⇒ 客户端放弃；405 = "资源在、方法不行" ⇒ 客户端改用 PROPFIND。
  · REPORT 打到容器 → **403**（参照实测也是 403）。
  · dav.php 与 carddav.php **两处同修**（同型孪生 bug）。

顺带对齐参照（「完全按参照返回」口径）：
  · 每个 XML 响应都带两行 `DAV:` 头（原来只有 OPTIONS 带）——
    CalDav::xmlHeader / CardDav::multis（所有 XML 响应的必经处）。
  · Content-Type 改 `text/xml`（参照的字面形态）。

探针补齐（这类 bug 长期漏网的三个原因）：
  · 原 TB 探针只发 PROPFIND/REPORT，**从不发 GET /dav/**；
  · curl 默认不跟随跳转（要 -L）；
  · 得先 GET .well-known 再跟到 /dav/ 才显形。
  ⇒ _fb_dav_tb.py 新增 ①c（follow=True 真跟跳转，断言跟随后不能 404、应为 405）；
     _fb_dav_tb.py 支持 FB_SITE（供反向验证指向注入副本）。

验证：
  · TB 探针 35 → **39/0**（新增 4 条 ①c 全过）
  · v45b DAV 反向验证 **7/0**（新增 2 个注入：dav/carddav 容器 GET 改回 404
    —— 都已证明会让断言变红）
  · 全流水线 PUSH_RC=0
  · 线上真机复验：跟随 well-known 的 GET 跳转 → CalDAV 405 / CardDAV 405
    （修复前都是 404）；PROPFIND 带两行 DAV 头 + text/xml；
    发现链 207、8 个日历本、1 个通讯录。
 2026-10-13 00:29:55 +08:00
laoyang 7544fb9f6a v41 第 41 批：流水线提速 + 12 项界面/交互开发 + DAV 彻底修复 
DAV（用户「务必彻底解决」）：
- 真根因是 home-set 层级错：CalDav::HOME_PATH 原为 /dav/calendars/、
  CardDav 原为 /carddav/addressbooks/，而日历本/通讯录的 href 在
  /dav/N.ics/ 与 /carddav/N.vcf/ —— home-set 下面一本都没有。
  Thunderbird 按 home-set 前缀认成员，于是「找不到日历本 / 找不到联系人」。
  改为 /dav/ 与 /carddav/（所有既有 URL 一字不变，老配置不作废）。
- 又发现并修掉 Depth:0 违反 RFC 4918：原实现无论 depth 都列出全部子集合，
  且第一条 response 是日历本（不含 current-user-principal）。改为按 depth 分流，
  Depth:0 只回资源自身、Depth:1 才列出子集合。

界面与交互：
- 观影：新建影院弹窗层级修正 + 详细地址；照片左右按钮悬停不再位移；
  弹框底栏改「确定 / 取消」。
- 旅程：新建旅程改弹窗并按观影式排版；详情页四个动作按钮按用户指定顺序与配色；
  编辑与新增行程弹窗化（单容器 + AJAX）；行程时间控件改 AntD（精确到分）；
  参与人默认带上自己；车次号/车牌号紧跟交通方式词。
- 资源：新建/编辑改弹窗 + 观影式排版 + 新建时即定共享人。
- 纪念日：新建改弹框 + 观影式排版。

验证：
- e2e 1510/0；v41 十二项真机 48/0；DAV 反向验证 8/0；
  部署断言空跑 337/0；模板 div 深度三形态穷举 33 组全配平。
- 线上 DAV 终验（--resolve 真实入口 + 真 DAV 口令）12/0；
  线上确认 Depth:0 恰好 1 个 response。
 2026-10-11 10:12:11 +08:00
laoyang be582569dd v31 第 31 批：DAV（CalDAV/CardDAV）同步修复 —— 发现链缺失 + ETag 潮汐 + 资源重复 
用户原话：「carddav 和 caldav 好像都不好用，没有任何数据被同步出来。
同步的客户端，在 D:/Yongquan/code/SyncCalendar 中有，你可以用这个里面的代码试试同步一下。」

三处真根因**全部靠实测**拿到（不是"看代码猜"）：写了 _fb_dav_diag.py，
逐字复刻 SyncCalendar 的 DavClient 请求序列（PROPFIND/REPORT/GET + 它那几个 XML 体），
打线上一次就复现出用户症状（15 条失败），修完线上 28/0。

1. 发现链（discovery）**整段缺失** ← 这就是"没有任何数据"的根因
   标准客户端（DAVx⁵ / iOS / SyncCalendar）建账号按 RFC 6764 走：
     GET /.well-known/caldav → 302 到 /dav/        ← 原来 404（落到 index.php 去登录页）
     PROPFIND <上下文路径> → current-user-principal ← 原来回的是"日历本清单"，没有 principal
     PROPFIND <principal> → calendar-home-set       ← 原来没这个属性
     PROPFIND <home> Depth:1 / <book> / REPORT      ← 这两步一直是通的
   ① 就断 ⇒ 客户端**在填完账号点保存那一刻**就失败，一条数据都拉不到。
   为什么历次验收全绿：上批只验了 PROPFIND /dav/ 与 /carddav/ —— 恰好是**一直通**的那两步，
   断点在其**前面**，从来没被测过。
   改：两个入口补 PRINCIPAL_PATH/HOME_PATH + /.well-known/* 301（**在鉴权之前**）+
   根/principal/列表三处都给 current-user-principal。.htaccess 用**独立标记块**追加
   well-known 重写规则（本仓库第 4 次"独立入口必须独立块"）。

2. DTSTAMP 取 time() → ETag 潮汐（增量同步**永远不收敛**）
   App\Ics::stampOf() 原为"没给时间就 time()"，而**派生条目**（观影/行程/生日/农历/
   节假日/节气）没有 updated_at/created_at ⇒ 每生成一次 ICS 就写一个新"现在" ⇒ 正文变
   ⇒ ETag 变。线上实测：同一本连续两次 REPORT **每一条 ETag 都不同**，整本 GET 的 ETag
   也在变 ⇒ 客户端把"增量同步"退化成"每轮全量重拉"，且拉回来的对不上、永远不收敛。
   改：缺时间写固定值 19700101T000000Z（确定优先于"诚实的当前时间"）。

3. 派生本把"日历视图条目"当"CalDAV 资源"
   Calendar::exportRows() 对派生本按**日历视图**取数（重复日程展开 N 次、跨天逐日、
   生日/农历逐日派生）。线上 /dav/1.ics/ 实测 **2981 个 response / 只有 196 个不同 href**
   （anniv-0_familybook.ics 自己重复 **2399** 次）。CalDAV 的资源是**一个 .ics 文件** ⇒
   客户端要么把同一条反复入库，要么判定服务器异常而中止本轮同步。
   改：CalDav::resources() 按 **UID 去重**（资源名本就是 UID）。

4. 连带两个真 bug（同一段代码顺出来的）
   · exportRows() 派生分支**没按本过滤**：month() 里"任务""纪念日"两段不带 kind 判断
     （它们 cal=0）⇒ 取"观影本"会把全家所有生日一起带出来（2981 条里绝大多数是 anniv）。
   · CalDav::parsePath() 的 $event=(int)$evSeg：派生资源名（movie-100_familybook）
     (int) 后全是 0 ⇒ 单条资源请求被当"整本"，GET /dav/4.ics/lunar-...ics 实测回 **400 条**。

5. 顺带补全：系统日历本（农历/节假日/传统节日/节气）原来**导出是空的**
   它们只走派生、没有 calendar_events 行，而 exportRows 只认 custom/movie/trip ⇒
   手机上订阅这几个本一条都没有。改：按 [今年-1, 今年+5] 派生（**封顶**，农历每天一条，
   130 年会有 4.7 万条）。实测耗时 lunarRange 31ms / traditional 51ms / Anniversary 30ms。

改：.htaccess、router.php、dav.php、carddav.php、app/CalDav.php、app/CardDav.php、
app/Calendar.php、app/Ics.php、templates/settings/me.php（补"或只填服务器地址"的提示）。

验证（全部 0 失败）：DAV 探针 28/0（**线上修前 15 失败 → 修后 28/0**，同一套探针两处都跑）、
DAV 反向验证 8/0（7 处修复各自改回旧行为，断言全变红）、e2e 1478/0、升级 153/0、
城市 32/0、几何 428/0 + 移动 680/0 + 交互 92/0、b24 41/0、b27 34/0、b28 39/0、b29 38/0、
b30_import 26/0、b30_ui2 16/0、b30_notify 23/0；部署静态断言新增 12 条守卫并逐条证伪通过。
线上 7 个文件 SHA256 与本地一致；/.well-known/caldav→301 到 /dav/ 实测生效。

⚠️ 本轮在部署脚本上真踩到并修掉两个坑（已写进 pitfalls.md）：
   · router.php **不发到线上**，把它写进部署断言 → grep "No such file" → 部署中止在
     "改了一半"的状态（迁到 push.sh 第 1 段）。
   · `set -euo pipefail` 下 `X=$(... | grep -c ...)` 在 **0 匹配**时退出码 1 ⇒
     **整个脚本静默退出**（不打 FAIL，日志停在上一行）。已给全部 7 处补 `|| true`。
 2026-10-08 20:05:01 +08:00
laoyang 6ceae11293 v24 第 22 批：名册加 CardDAV 同步 + 一把通用 DAV 口令（日历与通讯录共用） 
用户 2 条原话：
  ①「名册，增加cardav同步功能。」
  ②「caldav和cardav，都增加一个创建口令的功能，这样，就使用用户名和口令来同步，
     避免在第三方客户端进行同步时自己的密码泄露。」

用户拍板的两个岔路（AskUserQuestion）：
  · 口令范围 = **一把通用 DAV 口令**（日历 + 通讯录共用），不是两个 ——
    手机上填一次就都通；两把会让用户要在两个页面各配一遍、还容易只配一半。
  · 同步范围 = 与**名册页完全一致**（Person::roster(kind='member')），不另发明判据。

════ 一、 口令统一：caldav_credentials → dav_credentials（Schema v23）════
表**改名**（不是新建一张 carddav_credentials）：
  · 老站 RENAME → 已配好的口令一字不动，**所有设备不用重配**；
  · 新装时两表都不在 → 跳过（直接 RENAME 一张不存在的表会抛异常、把升级打断）；
  · 两表并存（上次升级跑一半 / 有人手工建过）→ 搬行（INSERT IGNORE）+ DROP 旧表。
⚠️ 迁移**必须**是 RENAME + 存在性守卫（新增 Schema::hasTable），
   只改建表语句里的名字的话，老库会**再建一张空表**、旧表留在原地没人读 →
   用户所有已配好的同步设备立刻全部 401（而且改密码也修不好：新口令写进了新表）。

Auth：caldavIssue/Revoke/Auth/hasCalDav → davIssue/davRevoke/davAuth/hasDav，
新增 davLastUsed()（UI 上显示"最近使用"）。

口令管理入口搬到**个人设置 → DAV 同步**（它管的是"我的凭据"，同时服务日历与通讯录；
放在日历页会让只想同步通讯录的人在日程里找半天）。
  · 旧路由 calendar/caldav_token|caldav_revoke 保留为 302 → 老书签不 404；
  · 日历本页只留地址 + 一个指路按钮（密码类的东西只该有一个管理入口，
    两处各放一套按钮迟早对不上：这页重置了、那页还显示"已配置"）。

════ 二、 CardDAV（全新）════
· app/Vcard.php —— 名册 → vCard **3.0**（iOS/DAVx⁵ 推荐；4.0 在 iOS 上会被降级丢字段）。
  FN 必须有（缺了 iOS 会**整张卡丢掉**）、UID 用 person id（稳定，不随改名变）、
  标签能对上固定词就走 TYPE（手机上显示成"手机/工作"），对不上就原样放进
  X-ABLabel（**不猜**成 HOME —— 猜错了用户看到"家"其实是"奶奶家"）。
· app/CardDav.php —— books/rows/one/cardOf/etag/parsePath；ROOT='/carddav/'。
· carddav.php —— OPTIONS / PROPFIND(0,1) / GET / REPORT；**写方法一律 403**。
  只读是与 CalDAV 同样的取舍：与其"半支持"（客户端以为改成功了、服务端却没落库），
  不如明确拒绝，用户至少知道"手机上加的联系人不会同步回来"。
· **地址空间分离、鉴权同一套**：/carddav/ 与 /dav/ 各自独立（资源类型与命名空间
  完全不同，混在一棵树里要靠猜客户端意图，猜错的表现是"连上了但一本都看不到"）；
  但两者调**同一个** Auth::davAuth、读**同一张** dav_credentials 表 ——
  这正是"一把口令管两种同步"的落点，也保证不会出现"日历能连、通讯录连不上"。
· 路由三处：router.php（本地 php -S）+ .htaccess（书面来源）+ 部署脚本 5c 段。
  ⚠️ 线上用**独立标记块** `# >>> FamilyBook CardDAV`：老站已经有
  `# >>> FamilyBook CalDAV`，把新规则并进那一段会被"标记在不在"的幂等判断
  **整段跳过** → /carddav/ 永远 404，而本地（走 router.php）完全正常。
· 打包白名单加 carddav.php（站点根下的独立入口最容易漏 —— dav.php / upload_stage.php
  都漏过一次，症状都是"线上那个功能 404、本地一切正常"）。

════ 三、 🔴 三个真 bug（全是"本地校验全绿"型，靠 vCard 往返测试抓出来）════
把 App\Vcard（导出）与 App\ContactImport（导入）各自单测都是绿的，
但**导出→导入跑一遍**立刻翻出三个：

 ① Vcard::fold **漏了"续行补前导空格"**（照抄 Ics::fold 时抄漏了最后一步）。
    后果：折出来的那几段变成**独立的属性行** → 客户端把半个名字/半个地址当垃圾丢掉。
    而"每行 ≤75 字节""确实折行了"全是绿的 —— 只有「**折行可无损还原**」这条断言能抓。

 ② ContactImport 用 `explode(';')` 给 ADR / N 分段 —— PHP 的 explode **不认识转义**，
    值里写了 `\;`（字面分号）照样在那里拆开 → 地址「青岛市,市南区;某某路1号」被
    从中间切断，后半截（含省名）跑到别的段上；导进来的人地址只剩前半句、
    而且看着像"省没填"。手机通讯录里带分号的地址（"XX路1号;3单元")不算罕见。
    → 新增 `splitVcardSegments()`：**按未转义的分号**切，切完再逐段 unescape。
    ⚠️ "先 unescape 再分段"是同一个错的另一种写法（本轮第一版就这么改，往返照样红）。

 ③ Vcard::adrField 的**分号数量对、但位置错一位**（省落到了"邮编"格）。
    第一版 `;;` + 街道 + `;;;` + 省 + `;` —— 总数也是 6，可多出来的那个挤在前面 →
    解析器读段 4 拿到空串。**段数对、总数对、只有位置错一位**，
    所以"数分号个数"的检查发现不了它。

════ 四、 顺带修的一个 ETag 一致性 bug ════
同一张卡在 PROPFIND（清单）与 REPORT（取正文）里原本算出**两个不同的 ETag**
（一个用不带结尾 CRLF 的正文、一个用带 CRLF 的）→ 客户端认为这张卡一直在变、
**反复重拉**（同步永远不收敛），而服务端看不出任何异常（两边都合法）。
→ 新增 `CardDav::cardOf()`，把**正文与 ETag 成对返回**，结尾 CRLF 只加在正文上、
不参与 ETag。修法不是"两处改成一样"，而是**让它们没有机会不一样**。

════ 五、 UI ════
· 个人设置页「DAV 同步」卡：两个地址（/dav/ 与 /carddav/）+ 用户名预填 + 一次性明文
  （只显示这一次，走一次性会话槽位）+ 生成/重置/撤销 + "最近使用"。
· 名册页 CardDAV 卡：地址 + "这 N 个人"（人数与名册页一致，用户当场能对上）+
  指路口令的按钮。**不放**生成表单。
· 日历本页改口径：只留 /dav/ 地址 + 指路链接。

════ 六、 验证 ════
- e2e **1106/0**（本批新增约 45 条：CardDAV 全协议、越权 404、只读 403、
  一把口令开两把锁、撤销后两处**同时**失效、口令一次性/不落库、ETag 一致性）
- **vCard 规格体检 36/36**（新工具 `_fb_b22_vcf_spec.php`：转义/折行/多值/标签/
  空名兜底 + **导出→导入往返一致**）
- **真机探针 28/0**（新工具 `_fb_b22_ui.py`：两块 UI 渲染、**在浏览器里点按钮**生成
  口令、刷新后明文消失但状态留下、名册页人数对得上、日历本页改口径、
  撤销后两处 401、全程零 JS 报错）
- 桌面几何 428/0 · 移动端几何（360/375/390/414）684/0 · 结构升级 149/0
- 部署静态断言空跑 **307/0** · 线上部署 134 项自检 0 失败
- **反向验证 14/14**（`_fb_b22_falsify.py`）：迁移不干活 / 读旧表 / 断入口 /
  去掉 addressbook 声明 / 只读守卫失效 / 不校验口令 / 越权不再查名册 /
  折行不补空格 / 分段改回 explode / ADR 错位 / UI 卡拿掉 / 明文不再一次性 /
  撤销不删凭据 —— 逐条改回旧行为，对应断言都变红，还原后复绿。

════ 七、 🔴🔴 线上实测挖出的**最重要**的一条：DAV 鉴权在 Apache 上一直是坏的 ════
部署后在线上以 **Web 用户(www)** 身份做端到端验收时，DAV 全部 401 ——
而本地 e2e 全绿。追下去发现两层原因：

 ① **测试假象**：我把 DAV 请求放进了一个**临时探针文件**里，用 `curl` 打它。
    但 Apache 请求 `.php` 文件时**不套用站点根 .htaccess 的 URL 重写** ——
    所以探针里的请求根本没被转给 dav.php/carddav.php，拿到的是**探针自己的 401**，
    不是 DAV 的。第一轮"全 401"有一半是探针自己造的假象。

 ② **真问题**：Apache 默认**不把 `Authorization` 头交给 PHP-FPM** ——
    `$_SERVER['PHP_AUTH_USER']` 与 `HTTP_AUTHORIZATION` **全是 null**。
    实测（这台服务器 Apache 2.4.53，直接监听 80/443，**没有 nginx**）：
        基线            : {"PHP_AUTH_USER":null,"HTTP_AUTHORIZATION":null}
        `CGIPassAuth On`: {"PHP_AUTH_USER":"abc","HTTP_AUTHORIZATION":"(有)"}
    ⇒ **线上 CalDAV 从来没被真实客户端连上过**（服务端代码是对的、环境少了这一行）。
      本轮 e2e 用 `php -S`，那里 `PHP_AUTH_USER` 是**自己填好的**，所以一路全绿 ——
      又一个"本地好好的、线上不行"。

  修法：部署脚本 5c 段追加**独立标记块** `# >>> FamilyBook DAV auth`，内容
  `CGIPassAuth On`（Apache **2.4.13+ 的核心指令**，不需要额外模块、**不用动宝塔面板**）。
  仓库 `.htaccess` 同步写上（它是那段规则唯一的书面来源）。

  修完后线上端到端**全部通过**（以 www 身份、真实 HTTP 服务、真实数据）：
    · CalDAV：`PROPFIND → 207`、**8 本日历本**、`PUT → 403`
    · CardDAV：根 `207` + `<card:addressbook/>`；清单 `207`、**1089 张卡**、1089 个 ETag；
      整本 vcf `200`、1089 张、全是 3.0、`text/vcard`；**最长行 75 字节**（真实数据上
      折行真的发生了）；`REPORT → 207` 带 `address-data`；`PUT → 403`；
      `OPTIONS → 200 DAV: 1, 2, 3, addressbook`
    · 导出的卡数 **1089 == 名册人数 1089**（口径一致）
    · 口令错 → `401`
  临时探针用完即删并复验 404；临时插入的口令用完即清（不动用户已配的凭据）。

════ 八、 关于 CalDAV「本来是好的」这件事 ════
严格说：**服务端实现一直是对的**，缺的是 Apache 那一行 `CGIPassAuth`。
也就是说这个仓库里的 CalDAV 之前**上线即不可用**（只是没人用真实客户端试过）。
本批顺手把它一起修好了 —— 现在 /dav/ 与 /carddav/ 都能被 iOS / DAVx⁵ 正常连上。
 2026-10-06 17:33:48 +08:00