在CALDAV场景下，有没有办法在不锁定账户的情况下顺利处理密码更改？
Is there a way to handle password changes smoothly in a CALDAV scenario without locking accounts?
我有一个场景 运行 自己的 CALDAV 服务器和 CALDAV 客户端，例如（iOS-日历，mac-日历，Android 同步适配器，Thunderbird/Lightning、Outlook 同步、...)
到目前为止，身份验证是通过基本身份验证（https 和 "Authentication"-Header）进行的。
CALDAV 客户端将 user/password 存储在它们的配置中。
到目前为止一切顺利，但是一旦 user/account 的密码被更改、重置、过期等，问题就来了。
服务器实施了限制性密码策略，在 x 次尝试失败（例如 10 次）后锁定帐户。
现在显然发生的情况是，一旦 CALDAV 客户端配置未更新，它就会继续使用旧密码。
服务器响应 401 未授权 - 好的，显然又没问题。
但客户端仍然继续使用过时的密码。最好停止轮询并向用户显示他的凭据不再有效的对话框。但是客户不在我的控制范围内，所以这里不能直接做任何事情。
结果：经过 2-3 次迭代（因为大多数客户端在一次同步迭代中尝试多个请求），用户服务器上的帐户由于登录尝试失败次数过多而被锁定。
这不太好。这个问题似乎很普遍，被称为 "stale passwords"。
解决方案只能是更好的客户端处理（超出此处范围）或 oAuth 令牌处理。但是我找不到标准 CALDAV 客户端支持的任何内容。只有 google 日历似乎在允许 CALDAV 通信之前强制执行 oAuth2 授权。
那么问题来了，有没有什么好的方法可以改善被锁账号的糟糕体验呢？
一些特殊的 401 响应告诉客户忘记密码或不再使用它？
非常欢迎建设性的反馈。
编辑：
对于 macOS 和 ios 日历，我发现一个奇怪的行为（错误）导致 and/or 强制执行所描述的情况。
标准的 401 响应将导致客户端按预期和上述方式调出密码对话框。客户端停止轮询，直到根据需要输入新密码。
在我的例子中，401 响应主体包含一个内联的 base 64 图像 (img src="data...")：
这不会导致密码更新对话框！只是 "something goes wrong" 错误状态。
客户正在继续投票！经过一些尝试后锁定帐户；（
这个问题的解决方案是删除内联图像，但对我来说这听起来像是一个错误，即 401 响应中的内联图像会在客户端引发不同的行为。
Some special 401 response which tells the clients to forget the password or not using it again?
嗯，401 就是那个响应。如果客户端收到 401，它知道它提供的 login/password 组合不再有效，并且不应重试。显然客户不这样做，部分原因是：
另一方面，出于显而易见的原因，您的服务器 x-failed-attempts 锁定不适用于无状态协议。 HTTP 没有内置该功能。当 运行 幂等 HTTP 请求时，锁定帐户是客户端不必期望的副作用。
假设客户端同时下载10批项目。如果凭证在此期间失效，该帐户将立即被锁定:-)
总结：您不能天真地使用基本身份验证与尝试 n 次后锁定帐户的后端。
Google 和 iCloud 都使用基于令牌的身份验证方案（Google OAuth，iCloud 是专有的）。你不能指望那些在其他客户中工作。例如。虽然 Apple 客户支持 Google 的 OAuth，但我认为他们不支持其他帐户类型。
那你能做什么
我正在阅读您的问题，您拥有帐户服务器并且帐户锁定是有意且需要的。 （也就是说，这不是您接触到的不同（例如 SSO）后端系统的副作用。）
我认为在这种情况下，重新设计您的帐户系统以允许仅使用旧密码进行无限制的登录尝试应该是合理的。
n 次尝试后锁定措施是为了防止人们尝试 不同的 密码。在您的情况下，它始终是相同的，并且作为奖励，它也与旧密码匹配。
这种方法有很多不同的变体。
我有一个场景 运行 自己的 CALDAV 服务器和 CALDAV 客户端，例如（iOS-日历，mac-日历，Android 同步适配器，Thunderbird/Lightning、Outlook 同步、...)
到目前为止，身份验证是通过基本身份验证（https 和 "Authentication"-Header）进行的。 CALDAV 客户端将 user/password 存储在它们的配置中。
到目前为止一切顺利，但是一旦 user/account 的密码被更改、重置、过期等，问题就来了。 服务器实施了限制性密码策略，在 x 次尝试失败（例如 10 次）后锁定帐户。
现在显然发生的情况是，一旦 CALDAV 客户端配置未更新，它就会继续使用旧密码。
服务器响应 401 未授权 - 好的，显然又没问题。
但客户端仍然继续使用过时的密码。最好停止轮询并向用户显示他的凭据不再有效的对话框。但是客户不在我的控制范围内，所以这里不能直接做任何事情。
结果：经过 2-3 次迭代（因为大多数客户端在一次同步迭代中尝试多个请求），用户服务器上的帐户由于登录尝试失败次数过多而被锁定。
这不太好。这个问题似乎很普遍，被称为 "stale passwords"。 解决方案只能是更好的客户端处理（超出此处范围）或 oAuth 令牌处理。但是我找不到标准 CALDAV 客户端支持的任何内容。只有 google 日历似乎在允许 CALDAV 通信之前强制执行 oAuth2 授权。
那么问题来了，有没有什么好的方法可以改善被锁账号的糟糕体验呢？ 一些特殊的 401 响应告诉客户忘记密码或不再使用它？
非常欢迎建设性的反馈。
编辑： 对于 macOS 和 ios 日历，我发现一个奇怪的行为（错误）导致 and/or 强制执行所描述的情况。 标准的 401 响应将导致客户端按预期和上述方式调出密码对话框。客户端停止轮询，直到根据需要输入新密码。 在我的例子中，401 响应主体包含一个内联的 base 64 图像 (img src="data...")： 这不会导致密码更新对话框！只是 "something goes wrong" 错误状态。 客户正在继续投票！经过一些尝试后锁定帐户；（ 这个问题的解决方案是删除内联图像，但对我来说这听起来像是一个错误，即 401 响应中的内联图像会在客户端引发不同的行为。
Some special 401 response which tells the clients to forget the password or not using it again?
嗯，401 就是那个响应。如果客户端收到 401，它知道它提供的 login/password 组合不再有效，并且不应重试。显然客户不这样做，部分原因是：
另一方面，出于显而易见的原因，您的服务器 x-failed-attempts 锁定不适用于无状态协议。 HTTP 没有内置该功能。当 运行 幂等 HTTP 请求时，锁定帐户是客户端不必期望的副作用。
假设客户端同时下载10批项目。如果凭证在此期间失效，该帐户将立即被锁定:-)
总结：您不能天真地使用基本身份验证与尝试 n 次后锁定帐户的后端。
Google 和 iCloud 都使用基于令牌的身份验证方案（Google OAuth，iCloud 是专有的）。你不能指望那些在其他客户中工作。例如。虽然 Apple 客户支持 Google 的 OAuth，但我认为他们不支持其他帐户类型。
那你能做什么
我正在阅读您的问题，您拥有帐户服务器并且帐户锁定是有意且需要的。 （也就是说，这不是您接触到的不同（例如 SSO）后端系统的副作用。） 我认为在这种情况下，重新设计您的帐户系统以允许仅使用旧密码进行无限制的登录尝试应该是合理的。 n 次尝试后锁定措施是为了防止人们尝试 不同的 密码。在您的情况下，它始终是相同的，并且作为奖励，它也与旧密码匹配。 这种方法有很多不同的变体。