我发现我认为对MembershipProvider来说这是一个非常讨厌的问题...我希望其他人已经遇到过这个并且优雅地解决了它。
我创建了一个在更改密码时计算密码强度的方法，以便我可以将其存储用于管理目的（审核，强制重置等）。因为我不想存储纯文本密码，所以这个值需要在密码更改期间计算。
更糟糕的是，我正在对现有代码库进行此改进，尝试不触及特定项目，尽可能支持次要配置更改。调用我的会员提供者的代码按此顺序调用：
的getUser 更改密码 UpdateUser两个
不幸的是，在ChangePassword之后调用UpdateUser会导致更新失败。对我而言，这似乎是提供者结构中的一个根本缺陷。需要ChangePassword来验证密码，但UpdateUser无法知道进行了哪些更改。
还有其他人遇到过这个问题吗？
注意：我了解我可以将更改密码工作流分开并完全避免使用UpdateUser。我试图不这样做，因为它需要我完全替换现有代码库的未来版本中可能更新的现有代码块。
答案 0 :(得分：0)
我通过派生一个新的MembershipUser并覆盖那里的ChangePassword来解决这个问题，在其基本调用中调用ChangePassword。
我调用了基本方法，如果结果为真，则将密码'metadata'构建到对象中。当在后面调用更新方法时，对象上存在正确的数据。
如果有人找到更好的解决方案，我会暂时搁置这个问题。