Graph demo component/controller in the hosted WASM project template?

[guardrex]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The ShowProfile component is referenced in the Blazor WebAssembly template (for the hosted option scenario) at ...

• https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/Client/Shared/NavMenu.CallsMicrosoftGraph.razor#L28
• https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/.template.config/template.json#L253

... and the controller (ShowProfileController) is mentioned at https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/.template.config/template.json#L254

... but the project template doesn't seem to have these any longer. I guess that they were removed at some point ...

• https://github.com/dotnet/aspnetcore/tree/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/Client/Pages
• https://github.com/dotnet/aspnetcore/tree/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/Server/Controllers

A generated hosted WASM project (7.0) with SingleOrg auth refers to the ShowProfile component in NavMenu.razor, but it isn't in the app ...

<div class="nav-item px-3">
    <NavLink class="nav-link" href="showProfile">
        <span class="oi oi-person" aria-hidden="true"></span> Show Profile
    </NavLink>
</div>

The only place I see the ShowProfile component these days is in the Blazor Server project template at ...

https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/BlazorServerWeb-CSharp/Pages/ShowProfile.razor

... and the Blazor Server template's ShowProfile component merely performs a straight Graph API call (GraphServiceClient.Me.Request().GetAsync()) (i.e., everything is done server-side, no web API-controller scenario is present and no controller).

ALSO, I mention in passing that the current .NET CLI help for --calls-graph doesn't mention that it's a scenario for hosted WASM, not standalone, at ...

https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/.template.config/template.json#L610

... which states ...

Specifies if the web app calls Microsoft Graph. This option only applies if --auth SingleOrg or --auth MultiOrg is specified.

... but single org auth is possible for a standalone WASM app, too. Nothing happens for standalone apps due to the requirement for the hosted WASM scenario ... you get no Graph config at all for standalone + SingleOrg. I wonder if that text should mention that it's only for hosted WASM ... 🤔 something like ...

Specifies if the app calls Microsoft Graph. This option only applies when the Blazor WebAssembly app is generated with an ASP.NET Core host using the -ho|--hosted option with --auth SingleOrg or --auth MultiOrg is specified.

... and I changed "web app," too.

Phrased another way ...

Specifies if the app calls Microsoft Graph. This option only applies if --auth SingleOrg or --auth MultiOrg is specified when the Blazor WebAssembly app is generated with an ASP.NET Core host using the -ho|--hosted option.

... and a third way ...

Specifies if the hosted Blazor WebAssemly app (-ho|--hosted option) calls Microsoft Graph. This option only applies if --auth SingleOrg or --auth MultiOrg is specified.

Expected Behavior

Since the hosted WASM app generated does have Graph configured in Program.cs of the server app ...

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
        .EnableTokenAcquisitionToCallDownstreamApi()
            .AddMicrosoftGraph(builder.Configuration.GetSection("DownstreamApi"))
            .AddInMemoryTokenCaches();

... it seems like the controller should be in the server app and a ShowProfile component should be in the client app to hit it up for user data. It seems like that would be the most helpful for devs who aren't familiar with what to do next and who aren't aware of our WASM Graph API topic. It's also consistent with internal NavMenu.razor naming of Client/Shared/NavMenu.CallsMicrosoftGraph.razor.

Otherwise, I suppose the template-generating config and NavMenu component would be refactored to remove these mentions/configurations.

Steps To Reproduce

Generate a 7.0 app with ...

dotnet new blazorwasm -ho -au SingleOrg --calls-graph

Check the NavMenu component to see the link, but there's no ShowProfile component in the app, and there's no ShowProfileController in the server project.

Exceptions (if any)

None other than the ShowProfile link going nowhere.

.NET Version

7.0.100

Anything else?

No response

[TanayParikh]

Potentially related to #42487

[ghost]

To learn more about what this message means, what to expect next, and how this issue will be handled you can read our Triage Process document.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious what is causing this behavior, we would like to keep this around to collect more feedback, which can later help us determine how to handle this. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact work.

[guardrex]

I did see that, but I thought that the underlying problem was fixed as part of a series of updates for 7.0 auth.

I'll post the link to that PR here when I get home. I'm OOF at the moment.

UPDATE: Actually, it doesn't look as related as I thought: #29384 and fixed by #43954. Since our topic uses a dedicated named HttpClient for Graph, I don't think there will be any problems with our topic. I test everything in it tomorrow, and I'll post an update to this comment on how it turns out.

UPDATE: I see what is meant by #42487 ... no way to delegate permissions to a WASM app for B2C.

Our Graph named-HttpClient approach and GraphServiceClient (Graph SDK) approaches, including for customizing user claims, for standalone WASM with AAD (not B2C) as described in the topic work well. Neither scenario works for B2C. Therefore, one of the updates to the topic will be to focus the guidance for AAD only.

[TanayParikh]

We aren't positive it's related, just cross-linking for now

[guardrex]

One more description NIT for consideration ...

The authorization option -au|--auth lists the following possible values:

• None
• Individual
• IndividualB2C
• SingleOrg

Cross-ref to the auth param in template.json: https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/.template.config/template.json#L338-L361

However, the Graph option description states ...

Specifies if the web app calls Microsoft Graph. This option only applies if --auth SingleOrg or --auth MultiOrg is specified.

"MultiOrg" of CallsMicrosoftGraph isn't in the authorization option list. It also appears in three other option descriptions in template.json for NoHttps, CalledApiUrl, and CalledApiScopes.

[ghost]

To learn more about what this message means, what to expect next, and how this issue will be handled you can read our Triage Process document.
We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. Because it's not immediately obvious what is causing this behavior, we would like to keep this around to collect more feedback, which can later help us determine how to handle this. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact work.

[mkArtakMSFT]

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.
You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.