最近群里有個小伙伴把Dapper遷移SqlSugar幾個不能解決的問題進行一個彙總，我正好寫一篇文章來講解一下 一、sql where in傳參問題： SELECT * FROM users where id IN @ids 答: SqlSugar中應該是 var sql="SELECT * FRO ...
分享給需要幫助的人：記一次 IdentityAPI 中註冊的源碼解讀，為什麼有這篇文? 因為當我看到源碼時，發現它的邏輯竟然是固定死的。我們並不是只能按照微軟提供的源碼去做。此文內容包含：設置用戶賬戶為未驗證狀態、延遲用戶創建、優缺點的說明、適用場景。
在ASP.NET 8 Identity 中註冊API的源碼如下：
routeGroup.MapPost("/register", async Task<Results<Ok, ValidationProblem>>
([FromBody] RegisterRequest registration, HttpContext context, [FromServices] IServiceProvider sp) =>
{
var userManager = sp.GetRequiredService<UserManager<TUser>>();
if (!userManager.SupportsUserEmail)
{
throw new NotSupportedException($"{nameof(MapIdentityApi)} requires a user store with email support.");
}
var userStore = sp.GetRequiredService<IUserStore<TUser>>();
var emailStore = (IUserEmailStore<TUser>)userStore;
var email = registration.Email;
if (string.IsNullOrEmpty(email) || !_emailAddressAttribute.IsValid(email))
{
return CreateValidationProblem(IdentityResult.Failed(userManager.ErrorDescriber.InvalidEmail(email)));
}
var user = new TUser { EmailConfirmed = false }; // 標記為未驗證
await userStore.SetUserNameAsync(user, email, CancellationToken.None);
await emailStore.SetEmailAsync(user, email, CancellationToken.None);
var result = await userManager.CreateAsync(user, registration.Password);
if (!result.Succeeded)
{
return CreateValidationProblem(result);
}
await SendConfirmationEmailAsync(user, userManager, context, email);
return TypedResults.Ok();
});
routeGroup.MapGet("/confirm-email", async Task<IResult>
([FromQuery] string userId, [FromQuery] string token, [FromServices] UserManager<TUser> userManager) =>
{
var user = await userManager.FindByIdAsync(userId);
if (user == null)
{
return TypedResults.BadRequest("Invalid user.");
}
var result = await userManager.ConfirmEmailAsync(user, token);
if (!result.Succeeded)
{
return TypedResults.BadRequest("Email confirmation failed.");
}
user.EmailConfirmed = true; // 更新為已驗證
await userManager.UpdateAsync(user);
return TypedResults.Ok("Email confirmed successfully.");
});
會發現它在註冊的時候使用郵箱作為用戶名，配置了郵箱和密碼。但是它在發送郵箱驗證碼之前，就已經通過CreateAsync創建好了賬號。這種方式叫做設置用戶賬戶為未驗證狀態，將 EmailConfirmed 設置為 false，郵箱驗證確認後設置為true。
這種方式的缺點很明顯：
- 資料庫冗餘：未驗證的用戶仍然會被創建並保存在資料庫中，可能會增加垃圾數據。
- 風險較高：未驗證用戶在短時間內可能會嘗試惡意行為，需要額外的監控和限制措施。
優點如下：
- 實現簡單：直接在用戶創建時標記用戶為未驗證，邏輯簡單易於實現。
- 用戶體驗：用戶可以立即註冊並部分使用系統功能，驗證郵箱可以稍後進行。
- 安全可控：通過限制未驗證用戶的操作，可以在確保全全性的同時提供基本的用戶體驗。
更安全的方式是延遲用戶創建，代碼如下：
routeGroup.MapPost("/register", async Task<IResult>
([FromBody] RegisterRequest registration, HttpContext context, [FromServices] IServiceProvider sp) =>
{
var userManager = sp.GetRequiredService<UserManager<TUser>>();
if (!userManager.SupportsUserEmail)
{
throw new NotSupportedException($"{nameof(MapIdentityApi)} requires a user store with email support.");
}
var userStore = sp.GetRequiredService<IUserStore<TUser>>();
var emailStore = (IUserEmailStore<TUser>)userStore;
var email = registration.Email;
if (string.IsNullOrEmpty(email) || !_emailAddressAttribute.IsValid(email))
{
return CreateValidationProblem(IdentityResult.Failed(userManager.ErrorDescriber.InvalidEmail(email)));
}
// 生成驗證令牌併發送確認郵件
var verificationToken = GenerateVerificationToken();
await SendVerificationEmailAsync(email, verificationToken, context);
// 臨時保存註冊信息
SaveTemporaryRegistrationInfo(registration, verificationToken);
return TypedResults.Ok("Please confirm your email.");
});
routeGroup.MapGet("/confirm-email", async Task<IResult>
([FromQuery] string token, [FromServices] IServiceProvider sp) =>
{
var registration = GetTemporaryRegistrationInfoByToken(token);
if (registration == null)
{
return TypedResults.BadRequest("Invalid or expired token.");
}
var userManager = sp.GetRequiredService<UserManager<TUser>>();
var user = new TUser();
await userStore.SetUserNameAsync(user, registration.Email, CancellationToken.None);
await emailStore.SetEmailAsync(user, registration.Email, CancellationToken.None);
var result = await userManager.CreateAsync(user, registration.Password);
if (!result.Succeeded)
{
return CreateValidationProblem(result);
}
return TypedResults.Ok("Email confirmed and user created.");
});
會發現它與第一個例子是相反的，它是用戶註冊後把數據保存在了臨時的記憶體中，再向郵箱發送驗證碼。通過配置郵箱的時候，用驗證碼得到用戶數據，並以此創建新的賬號。
此做法的缺點也很明顯：
- 實現複雜：需要額外的邏輯來保存臨時註冊信息並處理驗證令牌。
- 用戶體驗：用戶在註冊後需要先驗證郵箱才能完成註冊流程，可能會導致部分用戶流失。
優點如下：
- 避免垃圾用戶：只有當用戶驗證了郵箱後，才會正式創建用戶賬戶，減少垃圾用戶數量。
- 安全性高：在用戶點擊確認鏈接前，賬戶信息不會進入資料庫，降低被濫用的風險。
- 資源節省：避免創建大量未驗證的用戶，節省資料庫存儲和處理資源。
它們的適用場景如下：
- 延遲用戶創建：適用於希望最大限度減少垃圾用戶並確保用戶郵箱有效性的場景，如高安全性要求的系統。
- 設置用戶賬戶為未驗證狀態：適用於希望提供更流暢的用戶體驗，允許用戶在驗證郵箱前進行部分操作的場景，如社交平臺或內容網站。
