Identity 的 UserManager 什么時候不支持鎖定？

Question

ASP.NET Core Identity 有UserManager.SupportsUserLockout() ，這對我來說是真的。

描述：

獲取一個標志，該標志指示后備用戶存儲是否支持用戶鎖定。

用戶管理器是否有可能不支持鎖定？

Answer 1

用戶管理器是否有可能不支持鎖定？

是的

在這兩種情況中的任何一種情況下：

• UserManager<TUser>被子類化並且virtual bool SupportsUserLockout屬性被覆蓋並且該實現返回false 。
• UserManager<TUser>.Store （您的IUserStore<TUser>實現）沒有實現可選的IUserLockoutStore<TUser>接口。

---

• 如果您使用的是“庫存”收件箱 ASP.NET Core Identity 功能，而不使用任何自定義IUserStore實現（並且沒有子類化UserManager<TUser> ），那么您的運行時IUserStore<TUser>將是abstract class UserStoreBase<...>確實實現IUserLockoutStore<TUser> 。
  • 例如ASP.NET Core Identity for Entity Framework使用繼承了IUserLockoutStore<TUser>接口實現的Microsoft.AspNetCore.Identity.EntityFrameworkCore.UserOnlyStore 。
• 因為在 C#/.NET 中，接口是嚴格附加的（不能從 class 中“刪除”接口 - 你只能重新實現它）這意味着如果你不想子類UserManager<TUser>那么你將不能使用子類UserStoreBase<>作為重新實現IUserStore<>的基礎 - 基本上，您必須從頭開始。
  • （至少在我看來，這意味着 ASP.NET Core Identity 的默認組合UserManager和UserStoreBase<...>是一個糟糕的 OOP 設計，因為它需要通過大量的努力來實現 go 以正確地不支持某些東西，而不是讓一切都選擇加入。
  • 嘿孩子們，inheritance 很糟糕，mmm'key （好吧，不是“壞”，但至少充滿了應該避免的問題。
    • 子類 inheritance 是一個生硬的工具，尤其是在 C# 和 Java 中，不可能將類型的“接口”1 與實現分開，並且不能以類型代數的方式描述類型的接口——所以我們不能定義一個class Derived父類class Base: ISomeInterface的子類，這樣class Derived不再實現ISomeInterface （我們能做的最好的事情就是濫用隱式轉換為單獨的類型，或者使用[EditorBrowsable] “隱藏”成員並使用throw new NotSupportedException()顯式重新實現接口throw new NotSupportedException() ，這太可怕了，但即使是 Microsoft 在 .NET 的基礎庫中的某些地方也會這樣做，例如在Stream和TextWriter子類中）。
    • （此外，不要（ab）使用inheritance只是為了擁有不同類型的“普通成員”。我同意 C#/.NET 仍然不支持混合確實很糟糕，但是復制+粘貼轉發器屬性和從長遠來看，周圍的方法比處理不當使用 inheritance 的后果要痛苦得多。

1 ：“接口”不是指interface類型； 我的意思是class或struct的一組public成員，即類型的公開表面。

---

（在我的帖子的早期編輯中，我建議IConfigureOptions<LockoutOptions>可用於配置SupportsUserLockout ，但是我錯了：因為沒有選項可以完全禁用鎖定系統，但是如果您要將兩個LockoutOptions子類化以添加一個bool Enabled屬性和子類UserManager<TUser>以指定override bool SupportsUserLockout以返回LockoutOptions.Enabled （_{理想情況下，來自不可變副本，而不是原始可變選項 object} ）然后就可以了。