-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Add log event name for Identity #16879
Conversation
@@ -714,7 +714,7 @@ public virtual async Task<bool> CheckPasswordAsync(TUser user, string password) | |||
var success = result != PasswordVerificationResult.Failed; | |||
if (!success) | |||
{ | |||
Logger.LogWarning(0, "Invalid password for user {userId}.", await GetUserIdAsync(user)); | |||
Logger.LogWarning(LoggerEventIds.InvalidPassword, "Invalid password for user {userId}.", await GetUserIdAsync(user)); |
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.
I don't think we can just change log ids like this can we? @ajcvickers @blowdart is there some kind of guarantee with event ids being stable generally in logs?
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.
Yes, they are expected to remain stable.
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.
@Kahbazi so I guess if you are going to move to a variable for these, you are going to have to ensure that the order/values match.
Closing since this PR changes event ids |
@HaoK I forgot about this PR! I will change back the event ids. Can I continue on this PR or should I create a new one? |
You can continue using this one sure! |
3f067ee
to
c099cd1
Compare
@@ -291,7 +291,7 @@ public virtual async Task<TUser> ValidateTwoFactorSecurityStampAsync(ClaimsPrinc | |||
{ | |||
return user; | |||
} | |||
Logger.LogDebug(5, "Failed to validate a security stamp."); |
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.
Looks like we have different event ids for the same message, 4 and 5 due to different methods
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.
@Kahbazi I think its fine to introduce the logging extensions to the API which wasn't currently using event ids, but it doesn't look like its worth the potential regression in modifying the event ids for the sign in manager/existing apis. Unless you want to introduce a line by line method, so maybe lets just revert/delete LogginExtensions, but keep the LoggerEventIds changes
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.
I wanted to be consentience for each log. Should I delete LogginExtensions
completely and add event id to each logs?
Or add another method to LogginExtensions
for invalid security stamp?
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.
Right maybe the safest way to do it is https://github.com/dotnet/aspnetcore/pull/16879/files#diff-7d0bb5dd924f2d3e3de48da228cfbd19 so introduce a new file that's just the ids,, so no LoggingExtensions class like you said
c099cd1
to
fd4714c
Compare
@@ -138,7 +138,7 @@ public override async Task<IActionResult> OnPostAsync(string returnUrl = null) | |||
|
|||
if (result.Succeeded) | |||
{ | |||
_logger.LogInformation("User created a new account with password."); | |||
_logger.LogInformation(LoggerEventIds.UserCreated, "User created a new account with password."); |
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.
@blowdart any concerns with logging using an event id in the library and scaffolding still logging like before?
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.
Yes actually. If once you scaffold your log event ids change that's a bad thing. They need to match.
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.
So are you saying you prefer the UI just doesn't specify event ids? It seems bad to scaffold out a new file just to add event ids
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.
@Kahbazi I chatted with @blowdart offline and looks like this is pretty much ready to go except for one minor tweak, can you make the LoggerEventIds class public that the Identity UI code uses, since we want to be able to reference that in the scaffolded code. When we port these changes to the scaffolded pages
Thanks for making it public @Kahbazi unfortunately you will need to add doccomments for these now as well :/ |
Do I need to add documents for just the class or include each |
Sorry for the delay getting back to you @Kahbazi you will need to document public/protected just like everything else for apis, I don't think you need to go into much detail, for example: "Static class that exposes logging event ids." for the class summary, then something like "Event id when a user is created by an external provider." for UserCreatedByExternalProvider as an example. |
Hey @Kahbazi thanks for grinding through this, do you think you can try applying the relevant steps here to fix the issues with the public surface area? #24347 (comment) With step 7 being the only thing you really need to do, fixing the new api stuff I think, since you don't need to add the baseline files
Let me know if that doesn't work, I can take over the PR and merge it into one of my branches for the final step if the public api baselines don't update for you correctly |
6063ad1
to
cd53b2e
Compare
Thanks for sticking with this and getting this done @Kahbazi ! |
Identity/ApiAuthorization.IdentityServer
Addresses #6381