-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Root-level cascading values + CascadingAuthenticationState at root #49204
Conversation
Looks pretty straightforward. Since this is meant to handle the CascadingAuthenticationState, do you think we should flow the Principal automatically from static->interactive? With this fix, you get the cascading authentication state on the server, but you won't get nothing in webassembly, will you? |
TBH I'm not certain it's desirable to make the WebAssembly app think it has a particular authentication state that it didn't obtain itself. For example it could be misleading since the server may consider the WebAssembly app to have a different authentication state (different claims, at the very least) than existed during SSR. But either way, I think that should be considered out of scope for this PR. This PR is about providing a way that authentication state can be cascaded (once you have established some authentication state), rather than trying to solve other end-to-end problems about how the authentication state is determined in the first place. |
Implements #49104
Fixes #48927
See #49104 for the design. This PR includes a root-level equivalent to
<CascadingAuthenticationState>
and E2E tests showing it works in full-stack Blazor with an interactive@page
component.