ASP.NET Core Identity 具有UserManager.SupportsUserLockout()，這對我來說是正確的。
描述：
獲取一個標志，該標志指示后備用戶存盤是否支持用戶鎖定。
用戶管理器是否有可能不支持鎖定？
uj5u.com熱心網友回復：
用戶管理器是否有可能不支持鎖定？
是的
在這兩種情況中的任何一種情況下：
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使用
Microsoft.AspNetCore.Identity.EntityFrameworkCore.UserOnlyStore繼承IUserLockoutStore<TUser>介面實作。
- 例如ASP.NET Core Identity for Entity Framework使用
- 因為在 C#/.NET 中，介面是嚴格附加的（不能從類中“洗掉”介面 - 您只能重新實作它）這意味著如果您不想子類化
UserManager<TUser>，那么您將不能使用子類UserStoreBase<>作為基礎您的重新實作IUserStore<>- 基本上，您必須從頭開始。- （至少在我看來，這意味著 ASP.NET Core Identity 的默認組合
UserManager和UserStoreBase<...>是一個糟糕的 OOP 設計，因為它需要實作積極地通過大量努力來正確地不支持某些東西，而不是讓所有東西都選擇加入. - 嘿孩子們，繼承是不好的，嗯，關鍵（好吧，不是“壞”，但至少它充滿了應該避免的問題。
- 子類繼承是一種生硬的工具，尤其是在 C# 和 Java 中，不可能將型別的“介面”1 與實作分開，并且無法以型別代數的方式描述型別的介面 - 所以我們無法定義
class Derived子類class Base : ISomeInterface一個class Derived不再實作的父級ISomeInterface（我們能做的最好的事情是濫用隱式轉換為單獨的型別，或者用[EditorBrowsable]顯式“隱藏”成員并重新實作介面throw new NotSupportedException()，這很可怕，但即使微軟在 . NET 的基礎庫，例如 inStream和TextWriter子類）。 - （另外，不要（ab）使用繼承來擁有不同型別的“公共成員”。我同意C#/.NET 仍然不支持 mixins 確實很糟糕，但是復制 粘貼轉發器屬性和從長遠來看，與處理不恰當地使用繼承的后果相比，使用方法的痛苦要小得多。
- 子類繼承是一種生硬的工具，尤其是在 C# 和 Java 中，不可能將型別的“介面”1 與實作分開，并且無法以型別代數的方式描述型別的介面 - 所以我們無法定義
- （至少在我看來，這意味著 ASP.NET Core Identity 的默認組合
1：“介面”不是指interface型別；我的意思是or的public成員集，即型別的暴露表面。classstruct
（在我的帖子的早期編輯中，我建議IConfigureOptions<LockoutOptions>可以使用它來配置SupportsUserLockout，但是我錯了：因為沒有完全禁用鎖定系統的選項，但是如果您要同時創建子類LockoutOptions以添加bool Enabled屬性和子類UserManager<TUser>以指定override bool SupportsUserLockout回傳LockoutOptions.Enabled（理想情況下，從不可變的副本，而不是原始的可變選項物件）然后就可以了。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/428777.html