Authentication 在CALDAV场景中，有没有一种方法可以在不锁定帐户的情况下顺利处理密码更改？

我有一个使用自己的CALDAV服务器和CALDAV客户端（iOS日历、mac日历、Android同步适配器、Thunderbird/Lightning、Outlook同步等）运行的场景

到目前为止，身份验证是通过基本身份验证（https和“身份验证”-头）进行的。 CALDAV客户端在其配置中存储用户/密码

到目前为止还不错，但一旦用户/帐户的密码被更改、重置、过期等，问题就会出现。 服务器强制执行限制性密码策略，在尝试x次失败（例如10次）后锁定帐户

现在的情况显然是，一旦CALDAV客户端配置没有更新，它就会继续使用旧密码

服务器以401未授权响应-好的，很显然，这也没问题

但是客户端仍然继续使用过时的密码。最好停止轮询并向用户显示一个对话框，说明他的凭据不再有效。但是客户不在我的控制范围之内，所以这里不能直接做任何事情

结果：经过2-3次迭代（因为大多数客户端在一次同步迭代中尝试多个请求），由于登录尝试失败次数过多，用户服务器上的帐户被锁定

那可不好。这个问题似乎是一般性的，被称为“过时密码”。 解决方案只能是更好的客户端处理（此处超出范围）或oAuth令牌处理。但我找不到标准CALDAV客户机支持的任何东西。在允许CALDAV通信之前，似乎只有google calendar强制执行oAuth2授权

所以问题是，有没有一种好方法可以改善锁定账户的不良体验？ 一些特殊的401响应，告诉客户端忘记密码或不再使用密码？

非常欢迎有建设性的反馈

编辑： 对于macOS和ios日历，我发现一个奇怪的行为（bug）导致和/或强制执行所描述的情况。 标准401响应将导致客户端按预期和上述方式打开密码对话框。客户端将停止轮询，直到输入新密码（如需要）。 在我的例子中，401响应主体包含一个内联base 64映像（img src=“data…”）： 这不会导致密码更新对话框！只是一个“出错”的错误状态。 客户正在继续投票！尝试几次后锁定帐户；( 这个问题的解决方案是删除内联映像，但对我来说，401响应中的内联映像会在客户端引发不同的行为，这听起来像是一个bug

一些特殊的401响应告诉客户端忘记密码或不再使用密码

好的，401就是这个响应。如果客户端收到401，它知道它提供的登录/密码组合不再有效，并且不应该使用相同的组合重试。显然客户端不会这样做，部分原因是：

另一方面，服务器x-failed-attempts锁定不适用于无状态协议，原因显而易见。HTTP没有内置该功能。锁定帐户是客户端在运行幂等HTTP请求时不必预期的副作用

假设客户端正在同时下载10批项目。如果在此期间凭据无效，则帐户将立即被锁定：-）

小结：不能简单地将基本身份验证用于在n次尝试后锁定帐户的后端

Google和iCloud都使用基于令牌的身份验证方案（Google OAuth，iCloud是专有的）。你不能指望这些在其他客户身上起作用。例如，虽然苹果的客户支持谷歌的OAuth，但我认为他们不支持其他账户类型的OAuth

那你能做什么呢

我阅读您的问题是为了让您拥有帐户服务器，并且帐户锁定是有意的和需要的。（也就是说，这不是您接触的另一个（例如SSO）后端系统的副作用。） 我认为在这种情况下，重新设计您的帐户系统应该是合理的，只允许使用旧密码进行无限制的登录尝试。 n次尝试后锁定措施是为了防止人们尝试不同的密码。在您的情况下，它始终是相同的，作为奖励，它还与旧密码匹配。

---

这种方法有很多不同的变体。

谢谢，不幸的是我没有帐户服务器-我的caldav服务器作为应用程序服务安装在一些内置帐户服务器的基础结构之上。但我将尝试提出这种合理的方法：/“坐在上面”-这是否意味着您在传递它之前看到了身份验证？如果是这样，您可以在您的层中实现几乎相同的东西。如果登录尝试失败，请缓存特定组合的哈希。如果您看到另一次尝试使用相同的方法，只需返回401，而不必咨询后端。这一点很好！-这也是一个已经评估过的想法——我的基础设施没有将授权头传递给我——它会显式地清空授权头；（我想我发现了一个bug，它导致了所描述的锁定帐户的行为。一旦出现“正常”401响应，macOS和iOS日历可能会停止轮询，并希望有一个新密码（弹出对话框）。一旦401响应出现，其中包含一个内嵌的base 64映像作为响应正文的一部分，macOS日历不会弹出新密码对话框，而是告诉您出了问题，并继续按照指定的时间表进行轮询。这会强制执行锁定帐户的问题。对我来说，这听起来像是苹果方面的错误行为。拒绝g a 401 w/content可能是客户端中的一个错误：。但是，更大的错误似乎出现在您的代码中。客户端可以随时以非幂等请求为目标并重试服务器。您只需处理它。