URL.Page returns null unexpectedly

[gregoryagu]

This code returns null, instead of throwing an exception, when Area is used (Area/Identity...)

var callbackUrl = Url.Page(
                "/Account/ConfirmEmail",
                pageHandler: null,
                values: new { userId = userId, code = code },
                protocol: Request.Scheme);,

I ran into this and it was difficult to debug until I found this issue: aspnet/Mvc#8280

However, I think this is a bug, not a documentation issue as was concluded, because it the issue is hidden to the developer when it occurs.

In other words, to reproduce:

1. New Aspnet Core project is created using Identity. Everything works as expected.

2. Scaffolding of Identity is added, so that Identity is now under an Area.

But the generated page from the scaffolding includes:

var callbackUrl = Url.Page(
                "/Account/ConfirmEmail",
                pageHandler: null,
                values: new { userId = userId, code = code },
                protocol: Request.Scheme);,

instead of:

var callbackUrl = Url.Page(
                "/Account/ConfirmEmail",
                pageHandler: null,
                values: new { area="Identity", userId = userId, code = code },
                protocol: Request.Scheme);,

callbackUrl is now null, so the email that is generated now has a link that does not work, but no-one knows about it unless there is some testing of some sort or is reported by end user.

I don't know why it returns null, but it appears it is not finding the page, and so is returning null. Instead, it should thrown an exception, as there is never a case were you want the callbackURL to be null.

The other obvious point here is that the generated code should include the area so it works out of the box.

[chrisckc]

I encountered this unexpected null issue today, as @gregoryagu points out, there is never a case where it should return null, it should throw instead.

I have found that the behaviour is a bit different, when using Url.Page inside the razor pages inside the "Identity" area, the area="Identity" property is not required, it returns the correct url. That is how it's used inside the scaffolded Identity pages and it works fine. Adding area="Identity" also does not break it.

I found that only need to add area="Identity" when using url.Page outside of the Identity area Razor pages (Areas/Identity/Pages) like this:

// This code is used inside a service which is inside the Identity area at Areas/Identity/Services
// The service has an implementation of Microsoft.AspNetCore.Mvc.IUrlHelper injected
var callbackUrl = _urlHelper.Page(
                    "/Account/ConfirmEmail",
                    pageHandler : null,
                    values : new { area = "Identity", userId = user.Id, code = code },
                    protocol : request.Scheme);

The UrlHelper is added to the DI container like this:

services.AddSingleton<IActionContextAccessor, ActionContextAccessor>()
                .AddScoped(x => x.GetRequiredService<IUrlHelperFactory>()
                .GetUrlHelper(x.GetRequiredService<IActionContextAccessor>().ActionContext));

The /Account/ConfirmEmail only exists inside the Identity area Razor pages, so presumably that's why the area needs to be specified, although i am not sure why it has been designed to be a property of the "values" parameter, which seems to be used to create the url query parameters, despite the documentation stating "values" as: "An object that contains route values."

It's not obvious what this does, area = "Identity" is being used as some kind of magic query parameter which does not appear in the url.

[mkArtakMSFT]

Thanks for contacting us, @gregoryagu.
Looks like we need to update the IdentityUI to include the area parameter.

[mkArtakMSFT]

@HaoK can you please handle this? Thanks!