Dev authorization fakes

[DarthPedro]

Pull request description

For components that use the authentication and authorization, there is a lot of boilerplate code required to write to create a test. This code can be complex and needs to be copied into user's test projects each time.

Provide a set of "fake" authorization services that allow the user to choose and change the authentication/authorization state and user identification for a test. (closes #146)

PR meta checklist

• Pull request is targeting at DEV branch.
• Pull request is linked to all related issues, if any.
• I have read the CONTRIBUTING.md document.

Content checklist

• My code follows the code style of this project and AspNetCore coding guidelines.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• I have updated the appropriate sub section in the CHANGELOG.md.
• I have added, updated or removed tests to according to my changes.
  • All tests passed.

Todo checklist

• Does this cover all auth scenarios, e.g. both declarative in razor syntax and in c# code?
• Are there other types of claims that should be supported besides just basic/username? Is it relevant for testing? [DarthPedro] other claims can be really mocked based on what's required for a component or test. It shouldn't need fakes for that at this point. Blazor components like AuthorizeView and AuthorizeRouteView don't make use of claims.
• Test that we can correctly switch between authenticated and unauthenticated states.
• Create unit tests that covers the FakeAuthenticationStateProvider and FakeAuthorizationService. This can most likely be a regular unit test, maybe with a single component test in the mix to verify that e.g. AuthorizeView is compatible.
• Create a document page that describe how to use the FakeAuthenticationStateProvider
• Create a stub for FakeAuthenticationStateProvider (Register stubs of all default services Blazor provides at runtime with useful helper message #115) that is registered by default and provides the user with a good error message that tells how to register FakeAuthenticationStateProvider and link to docs. See example from JSMock at:
  • PlaceholderAuthenticationStateProvider.cs and PlaceholderAuthorizationService.cs.
  • TestServiceProviderExtensions.cs register the stubs in the AddDefaultTestContextServices.
• Code should be placed in src/bunit.web/TestDoubles/Authorization or something similar.
• Test code placement should mirror source code in src/bunit.web.test/TestDoubles/Authorization.
• Create extension methods for TestServiceProvider which supports registering with or without a username, e.g. Services.AddAuthorization() and Service.AddAuthorization("UserName", isAuthorized = true);

[egil]

Very solid start. Here are a few general comments:

• I haven't read through the docs and changelog text yet, since that might change once the API settles. Ill do proper review of those later.
• Well structured tests, good work on those.
• I sometimes to suggest a code change in one place, but that change should also be made in multiple other places, where the same thing happens.
• I focused mostly on reviewing the tests, as they are using the API you are building. I will return to the implementation in bunit.web when the API is settled.

[egil]

FYI: I have updated the dev branch with test-doubles as the name for the documentation section.

[egil]

I pushed some changes to the PR including refactored docs to fit the general style.

While documenting policies and roles i stumples onto something I think is a bug. I added a bunch of extra tests to the project, but in essens, the problem is content limited by roles and policies are always shown, even when inside a <AuthorizeView Roles="superuser"> component.

[DarthPedro]

I don't see any new pushed commits from you to the PR. Did you forget to push them? ;)

[egil]

Weird, I did not. But maybe I don't have the right remote set. Let me check and get back to you.

[egil]

Ahh, I managed to push a new branch to this repo with the changes: https://www.github.com/egil/bUnit/tree/dev-authorization-fakes/

Not sure how I add these to your PR without pushing directly to your local repo. Suggestions?

[DarthPedro]

That's weird. You pushed a commit into this PR earlier: 3e4b04d. Did you do that in my forked repo?

[egil]

Hmm nop. But I did pull the PR down using the gh pr pull command... Maybe that set something up. I'll have to check tonight after the kids are down for the night.

[egil]

OK, I managed to push it to this PR instead. It seems that when you use gh pr checkout 151 to review locally, you cannot change to another branch and come back again for a later review.

[DarthPedro]

Ok, I have your changes now. I will look at the failing tests.

[DarthPedro]

Fixed the AuthorizationService.AuthorizeAsync to validate authorization state based on requirements and either policies, roles, or authorization state. This covers all of the states we have, I believe.

I'll look at a SetClaims method as well though I'm not sure we'll be able to fake of the behavior that ClaimsPrincipal.Claims does.

[egil]

Just a quick review here on gh, see review comments on code below.

Regarding SetClaims, let's leave it for now and see if somebody asks for the feature.

What about a way to test asynchronous authentication, e.g. the state (https://docs.microsoft.com/en-us/aspnet/core/blazor/security/?view=aspnetcore-3.1#content-displayed-during-asynchronous-authentication), is it a hard thing to get working?

[DarthPedro]

I got both SetClaims and the AuthorizeView.Authorizing state working. Authorizing was a little tricky because how to get into that state is not documented. But I figured it out looking through the AuthorizeViewCore code.

[egil]

Awesome getting both claims and authorizing working. Ill update the docs tomorrow (I am on CET timezone) and play with the bits.

Found a few small things.

[egil]

@DarthPedro I changed the code a bit to make it possible to call SetAuthorizing() before RenderComponent. It was necessary as the code otherwise through a null pointer exception, since you were passing a null! in as the authentication state.

Please give my changes a review. If it looks alright, I'd say we are done!

[DarthPedro]

Ok, that looks good. Thanks for all of the help.

[egil]

Ok, that looks good. Thanks for all of the help.

No thank you. You almost all the work here!