Components auth step 2 #10293
Components auth step 2 #10293
Conversation
| @@ -29,6 +29,9 @@ public void ComputesCorrectBaseUri(string baseUri, string expectedResult) | |||
| [InlineData("scheme://host/path/", "scheme://host/path/", "")] | |||
| [InlineData("scheme://host/path/", "scheme://host/path/more", "more")] | |||
| [InlineData("scheme://host/path/", "scheme://host/path", "")] | |||
| [InlineData("scheme://host/path/", "scheme://host/path#hash", "#hash")] | |||
| [InlineData("scheme://host/path/", "scheme://host/path/#hash", "#hash")] | |||
| [InlineData("scheme://host/path/", "scheme://host/path/more#hash", "more#hash")] | |||
There was a problem hiding this comment.
Support for these cases was needed for the E2E tests. It's because we use a #server suffix to trigger server-side execution (and always have done - that's not new), and it turns out the ToBaseRelativePath logic didn't understand the case that's now on line 32 here.
src/Components/test/testassets/BasicTestApp/AuthTest/ServerAuthenticationStateProvider.cs
Show resolved
Hide resolved
| }; | ||
|
|
||
| await HttpContext.SignInAsync( | ||
| new ClaimsPrincipal(new ClaimsIdentity(claims, "FakeAuthenticationType"))); |
There was a problem hiding this comment.
Should we use the same scheme here? CookieAuthenticationDefaults.AuthenticationScheme - not sure that it matters.
There was a problem hiding this comment.
I slightly prefer specifying FakeAuthenticationType here because it clarifies that we're indifferent to the scheme name. But overall I agree it doesn't matter much!
| It exists so that (1) we can easily have multiple test cases that depend on the | ||
| CascadingAuthenticationState, and (2) we can test the integration between the router | ||
| and @page authorization rules. | ||
| *@ |
SteveSandersonMS
force-pushed
the
stevesa/auth-step-2
branch
from
ad9ac55 to
53b1e7b
Compare
…tiple such test components
... otherwise E2E test will fail, because we're using the hash to control server-or-client execution
SteveSandersonMS
force-pushed
the
stevesa/auth-step-2
branch
from
53b1e7b to
bd25b9b
Compare
| namespace BasicTestApp.AuthTest | ||
| { | ||
| // This is intended to be similar to the authentication stateprovider included by default | ||
| // with the client-side Blazor "Hosted in ASP.NET Core" template |
There was a problem hiding this comment.
Now I've written out this code, it makes me think we should consider making this more built-in, because it doesn't feel very friendly right now. We could ship a standard ServerAuthenticationStateProvider which developers explicitly add to their client-side Blazor DI config, along with some option about what URL it hits to get the state data. We'd also ship a standard ClientSideAuthenticationStateData DTO type (probably with a better name). Then the amount of boilerplate code in apps/templates would be pretty minimal (just some DI config plus UserController on the server), plus it's still possible to make your own entirely custom AuthenticationStateProvider if you don't like ours. Thoughts on this?
This PR is mainly about E2E tests for the previous auth work (#10227). It also contains a few commits that address remaining CR feedback from #10227.
Things to note:
ServerAuthenticationStateProvider,ClientSideAuthenticationStateData, andUserControllerclasses, you can now get a sense of how this feels when doing client-side Blazor. It's more involved than for server-side Blazor, because we have to fetch the authentication state from the server via an API request.