本文讲解如何通过为不同用户设置独立的认证 realm 来解决同一域名下多个 basic auth 用户在日历客户端（如 thunderbird lightning、macos 日历）中无法共存的问题，确保用户凭据隔离且不互相干扰。
本文讲解如何通过为不同用户设置独立的认证 realm 来解决同一域名下多个 basic auth 用户在日历客户端（如 thunderbird lightning、macos 日历）中无法共存的问题，确保用户凭据隔离且不互相干扰。
HTTP Basic Authentication 的核心机制依赖于 WWW-Authenticate 响应头中的 realm 字段。浏览器或日历客户端（如 Thunderbird Lightning、macOS Calendar）会将 域名 + realm 作为凭据缓存的唯一键（key）。这意味着：若所有资源使用相同 realm（例如 "Login"），客户端一旦缓存了某用户的凭证，后续请求将自动复用该凭据——即使访问的是另一个用户的专属资源（如 /user_a/calendar.ics vs /user_b/calendar.ics），导致权限校验失败后无法触发重新登录。
关键解决方案是：为每个用户动态生成唯一的 realm 值，使客户端将不同用户的认证视为完全独立的会话。
以下是一个生产就绪的实现示例：
<?php // 假设 $theCorrectUser 已从 URL 路径或路由中解析得出，例如 'user_a'
$auth = null;
// 尝试解析并验证 Basic Auth 凭据
if (isset($_SERVER['PHP_AUTH_USER']) && isset($_SERVER['PHP_AUTH_PW'])) {
$auth = login($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'], 'basic');
// 凭据有效但用户无权访问当前资源 → 返回 403，并提供该用户专属 realm
if ($auth->getUser() !== $theCorrectUser) {
$realm = 'Login for user ' . $auth->getUserIdent();
header('WWW-Authenticate: Basic realm="' . htmlspecialchars($realm, ENT_QUOTES, 'UTF-8') . '"');
header('Content-Type: text/calendar; charset=utf-8', true);
http_response_code(403);
echo 'Access denied: wrong user';
exit;
}
}
// 未提供凭据，或凭据无效 → 返回 401，并使用“通用但可区分”的 realm（建议含用户上下文）
if (!$auth) {
// 注意：此处 $auth 可能为 null，故需安全获取用户标识（如从路径推断）
$fallbackUser = basename(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), '.ics'); // 示例：/user_a/calendar.ics → 'user_a'
$realm = 'Login for user ' . htmlspecialchars($fallbackUser, ENT_QUOTES, 'UTF-8');
header('WWW-Authenticate: Basic realm="' . $realm . '"');
header('Content-Type: text/calendar; charset=utf-8', true);
http_response_code(401);
echo 'Authentication required';
exit;
}
// 认证通过且用户匹配 → 正常输出 iCalendar 内容
header('Content-Type: text/calendar; charset=utf-8');
echo file_get_contents(__DIR__ . '/' . $theCorrectUser . '/calendar.ics');
?>
✅ 关键要点说明：
- Realm 必须唯一且可区分：使用 Login for user user_a 和 Login for user user_b，而非统一的 Login。客户端据此分别存储两套凭据，互不覆盖。
- 403 响应也需携带 WWW-Authenticate：这是突破性设计——标准实践中常忽略此点，但 RFC 7235 明确允许 403 响应包含该头，用于提示客户端“凭据已识别但权限不足”，从而触发重试（部分客户端如 macOS Calendar 会据此弹出新登录框）。
- 安全加固：对 realm 中的用户标识进行 htmlspecialchars() 编码，防止 HTTP 头注入。
- 路径与用户映射需明确：确保 $theCorrectUser 严格来自可信来源（如路由解析），不可依赖客户端传入的任意参数。
⚠️ 注意事项：
- 某些旧版客户端可能对 403 + WWW-Authenticate 支持不佳；若遇兼容性问题，可考虑在 403 后重定向至一个带 query 参数的中间登录页（非纯 Basic Auth 方案）。
- 不要将敏感信息（如邮箱、ID）直接暴露在 realm 中；如需匿名化，可用哈希前缀（如 user_abc123）替代真实用户名。
- 测试时务必清除浏览器/客户端缓存凭据，或使用隐身模式验证多用户切换行为。
通过 Realm 隔离，你无需引入 Session、JWT 或复杂代理层，即可在标准 Basic Auth 架构下优雅支持多租户日历服务——简洁、兼容、符合 HTTP 规范。
