我有一个使用自己的CALDAV服务器和CALDAV客户端运行的场景(iOS-calendar,mac-Calendar,Android同步适配器,Thunderbird / Lightning,Outlook Sync ......)
到目前为止,身份验证通过基本身份验证(https和"身份验证" -Header)运行。 CALDAV客户端将用户/密码存储在其配置中。
到目前为止一直很好,但是一旦用户/帐户的密码被更改,重置,过期等问题就会出现问题。 服务器具有强制执行的限制密码策略,该策略在x次尝试失败后锁定帐户(例如10)。
现在发生的事情显然是,一旦CALDAV客户端配置未更新,它将继续使用旧密码。
服务器以未授权的401响应 - 好的,显然再次很好。
但客户仍然继续使用过时的密码。停止轮询并向用户显示他的凭据不再有效的对话框会更好。但是客户不在我的控制之下,所以在这里没有什么可以直接完成的。
结果:经过2-3次迭代(因为大多数客户端在一次同步迭代中尝试多次请求),用户服务器上的帐户因登录失败次数过多而被锁定。
这不太好。这个问题似乎是通用的,并且被称为过时的密码"。 解决方案只能是更好的客户端处理(超出范围)或oAuth-token处理。但我无法找到任何标准的CALDAV客户端支持这一点。在允许CALDAV通信之前,只有谷歌日历似乎强制执行oAuth2授权。
所以问题是,是否有一种改善锁定帐户不良体验的好方法? 一些特殊的401响应告诉客户忘记密码或不再使用它?
建设性反馈非常欢迎。
编辑: 对于macOS和ios日历,我发现了一个奇怪的行为(bug)导致和/或强制执行所描述的情况。 标准401响应将使客户端按预期和上面描述的方式调出密码对话框。客户端停止轮询,直到输入新密码 - 根据需要。 在我的例子中,401响应体包含一个内联基础64图像(img src ="数据......"): 这不会导致密码更新对话框!只是出现问题"错误状态。 客户正在继续投票!一些尝试后锁定帐户;( 这个问题的解决方案不是删除内联图像,但对我而言,这听起来像一个错误,401响应中的内联图像会在客户端上引发不同的行为。
答案 0 :(得分:1)
一些特殊的401响应告诉客户忘记密码或不再使用它?
嗯,401是那个回应。如果客户端收到401,则它知道它提供的登录/密码组合不再起作用,并且不应该使用相同的重试。显然客户不这样做,部分原因是:
另一方面,由于显而易见的原因,您的服务器x-failed-attempts锁定无法使用无状态协议。 HTTP没有内置的功能。锁定帐户是客户在运行幂等HTTP请求时不必要的副作用。
假设客户端同时下载10批商品。如果凭据在此期间失效,则帐户将立即被锁定: - )
摘要:您无法在n次尝试后锁定帐户的后端使用基本身份验证。
Google和iCloud都使用基于令牌的身份验证方案(Google OAuth,iCloud是专有方案)。你不能期望那些在其他客户中工作。例如。虽然Apple客户支持OAuth for Google,但我认为他们不支持其他帐户类型。
那你能做什么
我正在阅读您的问题,以便您拥有帐户服务器,并且帐户锁定是有意和有意的。 (即,它不是您接触到的不同(例如SSO)后端系统的副作用。) 我认为在这种情况下,重新设计您的帐户系统以允许使用旧密码进行无限次登录尝试应该是合理的。 锁定后尝试的措施是防止人们尝试不同的密码。在你的情况下它总是相同的,作为奖金它也匹配旧密码。 这种方法有很多不同的变化。