-
Notifications
You must be signed in to change notification settings - Fork 10.3k
[Blazor] Auth improvements #20073
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
[Blazor] Auth improvements #20073
Conversation
src/Components/WebAssembly/Authentication.Msal/src/Models/MsalProviderOptions.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes seem sensible to me based on the PR description.
/// <param name="services">The <see cref="IServiceCollection"/>.</param> | ||
/// <param name="configure">The <see cref="Action{RemoteAuthenticationOptions{MsalProviderOptions}}"/> to configure the <see cref="RemoteAuthenticationOptions{MsalProviderOptions}"/>.</param> | ||
/// <returns>The <see cref="IServiceCollection"/>.</returns> | ||
public static IServiceCollection AddMsalAuthentication<TRemoteAuthenticationState>(this IServiceCollection services, Action<RemoteAuthenticationOptions<MsalProviderOptions>> configure) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the configure
parameter isn't used. Am I missing something? Why don't we call it any more?
} catch (e) { | ||
reject(e); | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor stylistic point but rather than manually creating a promise and having a try/catch, it could do:
this._initialized = (async () => {
const userManager = await this.createUserManager(settings);
AuthenticationService.instance = new OidcAuthorizeService(userManager);
})();
@@ -15,7 +15,14 @@ | |||
<Found Context="routeData"> | |||
<AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)"> | |||
<NotAuthorized> | |||
<RedirectToLogin /> | |||
@if(!context.User.Identity.IsAuthenticated) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@if(!context.User.Identity.IsAuthenticated) | |
@if (!context.User.Identity.IsAuthenticated) |
Is there any chance we're a bit short on test coverage with some of this? It's unusual to be able to fix a wide range of issues without impacting or adding any tests. I'm particularly thinking about the DI parts here - there are a lot of different combinations of overloads. Do you think they would be amenable to unit testing, or can this only be seen at the E2E level? |
#19966
Multiple fixes for small issues in the auth packages:
<<authority>>/.well-known/openid-configuration