Aspnetcore.docs: Document changes between 3.2 and 5.0 docs

[captainsafia]

Since some users are upgrading from 3.2 to 5.0, they would like a summary of the differences between the two. Things like:

• SPA vs Web
• Disabling implicit grant

We also need to document the difference between what is auto-generated in VS and what actually works. @guardrex I think you might've already done this?

[guardrex]

It's in the migration topic starting with the following section, which includes improvements that I made this afternoon ...

https://docs.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio#standalone-blazor-webassembly-app-with-microsoft-accounts

document the difference between what is auto-generated in VS and what actually works

DR asked to leave our NOTE in place until VS receives the updates that it needs to do the right thing for apps that it creates. The NOTE is at the tops of our two AAD topics. For example ...

https://docs.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/standalone-with-azure-active-directory?view=aspnetcore-5.0

The idea is that the dev can use VS, but they need to go down the topic and correct any bad config using the guidance in the sections. He saw :eyes: the NOTE and didn't ask for changes, but I can test with VS and figure out what specific guidance to offer. If we go that way :ear:, is it ok if I work on it on Friday or Monday? I'm buried in Blazor WASM security at the moment. 😨😄

[guardrex]

Note that WRT the CORS issue, it came up on the docs repo at ...

https://github.com/dotnet/AspNetCore.Docs/issues/20482#issuecomment-725015546

I suppose we could use this issue to track two things (if you want to) ...

• Specifically determine and call out what VS is breaking in our NOTE and cross-link to the relevant section(s) for guidance.
• Head off whatever is causing this pesky CORS error that is cropping up for some devs. Will keep :eyes: on the engineering issue.

[captainsafia]

@guardrex I hadn't realized that we provided a warning about the differences between VS/CLI already.

Specifically determine and call out what VS is breaking in our NOTE and cross-link to the relevant section(s) for guidance.

Yep, this is what @javiercn was talking about writing docs for.

Head off whatever is causing this pesky CORS error that is cropping up for some devs. Will keep 👀 on the engineering issue.

As for the CORS stuff, at this point we're fairly confident that it is some funkiness in the way Azure AD behaves when you change app configs and not something in Blazor itself. I think we should avoid documenting anything until we've figured out what's up.

[guardrex]

I think we should avoid documenting anything until we've figured out what's up.

I'm :ear: on the engineering issue, and I'll open a new issue when the time comes to document something.

For now, I'll proceed to determine where VS is misconfiguring apps and make the NOTE more specific. I should be able to get that done this morning (but I have to leave around noon today, so it might be Saturday or Sunday morning).

UPDATE: Or, Monday. 😅🏃

[captainsafia]

@guardrex Sounds like a plan. Thanks, Luke!

[guardrex]

Several problems discovered ...

• It sets up the app registrations with implicit grant and a Web platform config.
• Although it sets up the server API with a correct API exposure and the app itself gets a correct default token scope, the client app registration in Azure is set up to expose an API and isn't configured to access the server API.
• The server API scope is wrong for an untrusted publisher domain. It sets up the apps in the solution with the api:// scope, but the server API registration uses the https:// format for an untrusted publisher domain.
• The server API app's ClientID is wrong ... it's placing the API scope into the value in appsettings.json. It's also not adding the Authority for an untrusted publisher domain.

It's badly broken and would require a lot of (temporary) text to explain the correct setup, so it seems like we're taking the right direction to be general in the NOTE about what needs to be addressed.

The current NOTE reads ...

For Blazor WebAssembly apps created in Visual Studio that are configured to support accounts in an AAD organizational directory, Visual Studio doesn't configure the app correctly on project generation. This will be addressed in a future release of Visual Studio. This article shows how to create the app with the .NET Core CLI's dotnet new command. If you prefer to create the app with Visual Studio before the IDE is updated for the latest Blazor templates in ASP.NET Core 5.0, refer to each section of this article and confirm or update the app's configuration after Visual Studio creates the app.

It should further say ...

• It isn't just the app ... the app registrations are bad, too.
• Also, I should refactor a bit and talk about the solution instead of the app. Both projects in the solution need work after VS creates it.

I'll put the following on a PR for this and ping u for review ...

For Blazor WebAssembly apps created in Visual Studio that are configured to support accounts in an AAD organizational directory, Visual Studio doesn't configure the solution's projects or the Azure portal app registrations correctly on project generation. This will be addressed in a future release of Visual Studio.

This article shows how to create the solution and Azure app portal registrations with the .NET CLI dotnet new command and by manually creating the app registrations in the Azure portal.

If you prefer to create the solution and Azure app registrations with Visual Studio before the IDE is updated, refer to _each section of this article_ and confirm or update the apps' configurations and the apps' registrations after Visual Studio creates the app.