Move the token providers into the Volo.Abp.Identity namespace
- One namespace no longer spans two assemblies now that they live in the domain layer
- The Data Protection purpose keeps its old string, so outstanding 2FA codes stay valid
@ -145,7 +145,7 @@ Add a navigation property to the principal entity if you rely on the previous be
**What changed**
- The ABP token providers and their options moved from the `Volo.Abp.Identity.AspNetCore` assembly to `Volo.Abp.Identity.Domain`, and are now registered by `AbpIdentityDomainModule` instead of `AbpIdentityAspNetCoreModule`. An assembly compiled against an earlier version and not rebuilt cannot resolve them.
- The ABP token providers and their options moved from the `Volo.Abp.Identity.AspNetCore` assembly to `Volo.Abp.Identity.Domain`, out of the `Volo.Abp.Identity.AspNetCore` namespace and into `Volo.Abp.Identity`, and are now registered by `AbpIdentityDomainModule` instead of `AbpIdentityAspNetCoreModule`. An assembly compiled against an earlier version and not rebuilt cannot resolve them. The types that stay in the ASP.NET Core layer, such as `AbpSignInManager` and `AbpIdentityAspNetCoreOptions`, keep their namespace.
- Every host that loads `AbpIdentityDomainModule` therefore resolves the same providers, unless it registers something else itself. Previously the providers were only registered on hosts loading `AbpIdentityAspNetCoreModule`, so a host that generated a token could end up on a different provider than the host that validated it, and the link was rejected as an invalid token.
- `AbpSingleActiveTokenProvider` no longer derives from ASP.NET Core's `DataProtectorTokenProvider<IdentityUser>`; it implements `IUserTwoFactorTokenProvider<IdentityUser>` and re-implements the same protected payload, so the token format is unchanged. Code that casts a provider to `DataProtectorTokenProvider<IdentityUser>` or uses it as a generic constraint no longer compiles, and the `Logger` property the old base class exposed publicly is now protected.
- The provider options classes derive from `AbpDataProtectionTokenProviderOptions` instead of `DataProtectionTokenProviderOptions`. The `Name` and `TokenLifespan` properties are unchanged, but code that assigns one of them to `DataProtectionTokenProviderOptions`, passes it to a method taking that type, returns it, or uses it as a generic constraint no longer compiles.
@ -155,6 +155,7 @@ Add a navigation property to the principal entity if you rely on the previous be
**What to do**
- Replace `using Volo.Abp.Identity.AspNetCore;` with `using Volo.Abp.Identity;` where you use one of the moved types, or add the second one when the file also uses a type that stayed behind.
- Rebuild the solution. No further action is required for the common case: configuring the options and the provider names works exactly as before, and the compiler points at the source level changes below. The assembly move is not one of them, so a package you depend on that was built against the old assembly has to be rebuilt and republished against v10.7 as well.
- If you derive from one of the five DataProtector-based providers, change the logger parameter to `ILogger<AbpSingleActiveTokenProvider>`.
- If you derive from `AbpSingleActiveTokenProvider` directly, give your provider its own options class deriving from `AbpDataProtectionTokenProviderOptions` and inject `IOptions<YourTokenProviderOptions>`, the way the built-in providers do. `IOptions<T>` is covariant, so it satisfies the base constructor. Do not inject `IOptions<AbpDataProtectionTokenProviderOptions>`: the base options class is abstract and the options system cannot create it.
maliming
3 days ago