Skip to content

Conversation

@luccawilli
Copy link
Contributor

@luccawilli luccawilli commented Sep 9, 2022

Better logs in AuthorizationMiddleware

  • You've read the Contributor Guide and Code of Conduct.
  • You've included unit or integration tests for your change, where applicable.
  • You've included inline docs for your change, where applicable.
  • There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary of the changes (Less than 80 chars)

Description

Added a logger to AuthorizationMiddleware and log not succeeded policies with Debug-Level

Fixes #43861

@luccawilli luccawilli requested review from a team and Tratcher as code owners September 9, 2022 07:06
@ghost ghost added area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer community-contribution Indicates that the PR has been added by a community member labels Sep 9, 2022
@ghost
Copy link

ghost commented Sep 9, 2022

Thanks for your PR, @luccawilli. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

@dnfadmin
Copy link

dnfadmin commented Sep 9, 2022

CLA assistant check
All CLA requirements met.


if (authenticateResult != null && !authenticateResult.Succeeded)
{
_logger.LogDebug("Policy authentication schemes {policyName} did not succeed", String.Join(", ", policy.AuthenticationSchemes));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about logging this in the policyEvaluator instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be also an option.
I just wanted as few log entries as possible. For me, it would have been enough to know that the combination does not work instead of each individual policy.

@davidfowl
Copy link
Member

@halter73 now is the time when you say I told you so 😄

@halter73
Copy link
Member

halter73 commented Sep 9, 2022

I'm not sure I follow @davidfowl. This isn't changing the logging in the if (endpoint?.Metadata.GetMetadata<IAllowAnonymous>() != null) branch where we were over logging before does it?

@Tratcher merged the PR that issue anyway. We didn't end up just not logging authentication failures for anonymous endpoints like I suggested. We did something else. Or are we talking about something else?

#nullable enable
Microsoft.AspNetCore.Authorization.AuthorizationMiddleware
Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.AuthorizationMiddleware(Microsoft.AspNetCore.Http.RequestDelegate! next, Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider! policyProvider) -> void
Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.AuthorizationMiddleware(Microsoft.AspNetCore.Http.RequestDelegate! next, Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider! policyProvider, Microsoft.Extensions.Logging.ILogger<Microsoft.AspNetCore.Authorization.AuthorizationMiddleware!>! logger) -> void
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously shipped APIs can't be modified. You need to add new overloads instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thank you for the tip, I wasn't sure how to handle that😅

@davidfowl
Copy link
Member

I'm not sure I follow @davidfowl. This isn't changing the logging in the if (endpoint?.Metadata.GetMetadata() != null) branch where we were over logging before does it?

I mean making this middleware internal and adding the impl so we don't need public APIs to add dependencies.

/// <param name="policyProvider">The <see cref="IAuthorizationPolicyProvider"/>.</param>
/// <param name="services">The <see cref="IServiceProvider"/>.</param>
public AuthorizationMiddleware(RequestDelegate next, IAuthorizationPolicyProvider policyProvider, IServiceProvider services) : this(next, policyProvider)
/// <param name="logger">The <see cref="ILogger"/>.</param>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we feel about just service locating ILogger<AuthorizationMiddleware> so we don't have to add any new ctors, that would simplify the change a lot

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the longest constructor should be called by DI, I don't think we need the other new combinations. One new constructor isn't a big deal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@luccawilli can you remove all the extra new constuctor overloads except the one we need

@HaoK
Copy link
Member

HaoK commented Oct 7, 2022

Thanks @luccawilli

@HaoK HaoK merged commit 4cd47a5 into dotnet:main Oct 7, 2022
@ghost ghost added this to the 8.0-preview1 milestone Oct 7, 2022
@luccawilli luccawilli deleted the log-authentiation-schemes-did-not-succeed branch October 10, 2022 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer community-contribution Indicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Better logs for not succeeded policy authentication schemes

6 participants