Registration confirmation link incorrect for /register endpoint in net8.0 Identity

[freever]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

I am using the new ASP.NET Identity APIs available in .net8. When I call the /register endpoint An email is sent to the registered email address (once you have configured an email sender) but the format of the link is incorrect. For example, here is a link that was generated in a local instance:

https://localhost:7300/confirmEmail?userId=7917bb50-0155-4c47-bc7b-aaa9d708bc4a&code=Q2ZESjhQY21oS0s0dXpKSW16MndPMjd1V1NQY1Q3RlJiT2NsdE9RQXd1VDdsWXpzZXFvcXFMa1RpUGdTTXg5a1ZDUm5oZGVWU0xjNEVnLzdtdGgvU2dEektadFBKRm1HeGFmVGZMWmMyQ25ja1I4NmZtZFhxTVFhNG8zOTlJVWc2cVlxTXZaeElBQnhlb09CWDlGQndUSk9DVzNYRCtITHJWa3luNUdOcDZHQ013NjE5dUhQdExJbFhFc2RkY3U4ZmxMV0lEUFpFNlhSYzVMblhZdExDckkwcU5KbjhnRUxCQzFZZ2U2T3ZEOE9NZ0hOZmY2SE5MZU1PUlNmamFzRjJEdVZXUT09

Clicking on this link results in an error: "BadHttpRequestException: Required parameter "string code" was not provided from query string."

If I modify the link to replace &code= with &code= then the link works and I see "Thank you for confirming your email."

Expected Behavior

Expected behaviour is that the generated link should confirm the account when clicked on without needing any modification.

Steps To Reproduce

Run the attached solution after updating the database. Put a breakpoint in the FakeEmailSender SendConfirmationLinkAsync method to capture the link. Go to /swagger and execute the register endpoint with a valid email and password. Grab the link from the debugger and paste it into the browser.

LinkErrorRepro.zip

Exceptions (if any)

BadHttpRequestException

.NET Version

8.0.100

Anything else?

.NET SDK: Version: 8.0.100 Commit: 57efcf1350 Workload version: 8.0.100-manifests.71b9f198

Runtime Environment: OS Name: Windows OS Version: 10.0.22621 OS Platform: Windows RID: win-x64 Base Path: C:\Program Files\dotnet\sdk\8.0.100\

.NET workloads installed: Workload version: 8.0.100-manifests.71b9f198 [aspire] Installation Source: VS 17.9.34310.174 Manifest Version: 8.0.0-preview.1.23557.2/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.0-preview.1.23557.2\WorkloadManifest.json Install Type: Msi

[android] Installation Source: VS 17.9.34310.174, VS 17.8.34316.72 Manifest Version: 34.0.43/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.android\34.0.43\WorkloadManifest.json Install Type: Msi

[wasm-tools-net7] Installation Source: VS 17.9.34310.174 Manifest Version: 8.0.0/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.workload.mono.toolchain.net7\8.0.0\WorkloadManifest.json Install Type: Msi

[maui-windows] Installation Source: VS 17.9.34310.174, VS 17.8.34316.72 Manifest Version: 8.0.3/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maui\8.0.3\WorkloadManifest.json Install Type: Msi

[maccatalyst] Installation Source: VS 17.9.34310.174, VS 17.8.34316.72 Manifest Version: 17.0.8478/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maccatalyst\17.0.8478\WorkloadManifest.json Install Type: Msi

[ios] Installation Source: VS 17.9.34310.174, VS 17.8.34316.72 Manifest Version: 17.0.8478/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.ios\17.0.8478\WorkloadManifest.json Install Type: Msi

[wasm-tools] Installation Source: VS 17.8.34316.72 Manifest Version: 8.0.0/8.0.100 Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.workload.mono.toolchain.current\8.0.0\WorkloadManifest.json Install Type: Msi

Host: Version: 8.0.0 Architecture: x64 Commit: 5535e31a71

.NET SDKs installed: 8.0.100-preview.4.23260.5 [C:\Program Files\dotnet\sdk] 8.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.0-preview.4.23260.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.0-preview.4.23259.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.0-preview.4.23260.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

[ninety7]

This seems to be a bug within the templates. I'm experiencing this issue with blazor: On the Register and ResendEmailConfirmation pages, the send email confirmation call is sending HtmlEncoder.Default.Encode(callbackUrl) as the confirmation link parameter, which is changing the & character in the query string into &. Blazor will not recognize the code query string parameter because of this, and the user will never be confirmed.

As I don't expect the generated URL to have encoding issues, I've removed the HTML encoding of the call for the callbackUrl parameter, but I expect Microsoft to acknowledge the issue and fix it.

[freever]

Thanks @ninety7 I am not using the templates, I am using the API endpoints (which presumably use the same code) so MS will have to fix it there as we don't get access to the source code for the endpoints like we do for the templated pages.

[Kahbazi]

After many struggles I think the way it works is that the callback url is supposed to be in href of a tag and it is encoded by design so when sent via email as an html it would be correct.

https://github.com/dotnet/aspnetcore/blob/459a4884bf3ccd1f50ada2244a6c2da6a939ae0d/src/Shared/DefaultMessageEmailSender.cs#L13

So when you put a breakpoint in FakeEmailSender it is supposed to be encoded.

[ninety7]

Thanks for the fix, @Kahbazi. I agree that the encoding should be done in the EmailSender class implementation, instead of in the caller. That way we avoid these kinds of issues.

[mkArtakMSFT]

Thanks for helping here, @Kahbazi! That's exactly right!