How to debug mis-configured setup? about active-directory-b2c-dotnetcore-webapp

[phatcher]

Can I have some response please!

[phatcher]

@parakhj yet again no response from anyone in your team

[parakhj]

Apologies @phatcher. The URL's, while different, do the same thing. Some OIDC libraries don't like the fact that there is a non-standard parameter (the p parameter for policy), so we have to provide a URL format that has the policy in the path.

For quicker replies, I encourage also posting on stackoverflow, using the tag 'azure-ad-b2c'. There are a lot more people monitoring that

[phatcher]

@parakhj No if you are going to post examples here, it makes sense to support them here. Also the only question posted on SO regarding this example has no replies apart from the author.

If you are not going to support these examples directly, make it clear in the documentation page of the project.

What's not clear from the documentation is that from the .NET to the dotnetcore version you must change the reply url in the Azure B2C tenant to include "signin-oidc" i.e. if you previously had "https://localhost:44316" you must also add "https://localhost:44316/signin-oidc" for the dotnetcore client code to work

[parakhj]

The redirect URL is something you have full control over. It's just a matter of what URL the application is listening at. The .dotnetcore convention is to add the code that listens to the reply behind the path specified by /signin-oidc at the end. However, your code could handle it at the root level as well. It's just how you implement it

[phatcher]

@parakhj From what I can see yes we do have full control over the reply url, however we must append /signin-oidc to the registered url in the Azure B2C tenant, or whatever string is assigned to OpenIdConnectOptions.CallbackPath, which won't except an empty string.

So from my perspective, this is a breaking change since I didn't have to do this for the standard .NET WebApp code and you have failed to adequately document this - I say this because there are about four open issues here which are all about this problem.

When you say "your code could handle it at the root level", can you explain what you mean by this?

[parakhj]

Ah okay. Thanks for clarifying that - didn't properly acknowledge that you are migrating from your .NET webapp code.
Sure I'll work on making the instructions more clear.

[jmprieur]

Closing this issue as this sample is being archived and replaced by a newer ASP.NET Core 3.1 sample.
See Readme.md