Skip to content
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

Adding HttpLogOptions for Logging improvements #5688

Merged
merged 7 commits into from
Oct 7, 2019

Conversation

samvaity
Copy link
Member

@samvaity samvaity commented Oct 4, 2019

Reference #4154

/**
* Logs everything in QUERY PARAMS.
*/
QUERY_PARAMS;
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't quite make sense - if the user opts in for QUERY_PARAMS, that means that they can't also get BODY or BODY_AND_HEADERS.

Copy link
Member Author

Choose a reason for hiding this comment

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

so should we keep the requirement to log query params on only BODY or BODY_AND_HEADERS or both?

Copy link
Member

Choose a reason for hiding this comment

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

BASIC indicates log url (that includes query parameter) and skip headers & body. Wondering why we need QUERY_PARAMS enum option for a specific part of url, Does guideline enforce it?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think the guideline enforces to have the QUERY_PARAMS enum. It can be removed, but still, not sure if we need BODY_AND_HEADERS with it.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, remove QUERY_PARAMS. Leave the rest as-is I would think.

@@ -115,7 +120,40 @@ public HttpLoggingPolicy(HttpLogDetailLevel detailLevel, boolean prettyPrintJSON
return reqBodyLoggingMono;
}

private Function<HttpResponse, Mono<HttpResponse>> logResponseDelegate(final ClientLogger logger, final URL url,
private void formatAllowableHeaders(Set<String> allowedHeaderNames, HttpRequest request, ClientLogger logger) {
Copy link
Member

Choose a reason for hiding this comment

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

@samvaity / @JonathanGiles does guideline proposes different meaning for empty vs null value for allowedHeaderNames? i.e. something like empty set means redact all headers and null means log all headers?

Copy link
Member Author

@samvaity samvaity Oct 4, 2019

Choose a reason for hiding this comment

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

I was also thinking if we should add something like a "*", to say log all headers maybe..

Copy link
Member

Choose a reason for hiding this comment

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

At present null and empty set should mean the same thing - to not print any headers.

@samvaity samvaity force-pushed the logging-redaction branch 3 times, most recently from ff415ac to 2feba11 Compare October 4, 2019 20:17
Copy link
Member

@JonathanGiles JonathanGiles left a comment

Choose a reason for hiding this comment

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

Looks good. Just a few minor things to consider.

policies = new ArrayList<>();
httpLogOptions = new HttpLogOptions().setLogLevel(HttpLogDetailLevel.NONE);
Copy link
Member

Choose a reason for hiding this comment

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

It probably makes sense to just have the log level be NONE by default.

public ConfigurationClientBuilder httpLogDetailLevel(HttpLogDetailLevel logLevel) {
httpLogDetailLevel = Objects.requireNonNull(logLevel);
public ConfigurationClientBuilder httpLogOptions(HttpLogOptions logOptions) {
httpLogOptions = Objects.requireNonNull(logOptions, "Http log options cannot be null.");
Copy link
Member

Choose a reason for hiding this comment

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

We should probably allow null now that I think about it - this lets the user clear out the configuration in the builder so that the next time they call build, they will get an HttpLoggingPolicy with null options. This also means you need to have HttpLoggingPolicy know what to do if the options are null!

* @throws NullPointerException If {@code logLevel} is {@code null}.
*/
public HttpLogOptions setLogLevel(final HttpLogDetailLevel logLevel) {
this.logLevel = Objects.requireNonNull(logLevel);
Copy link
Member

Choose a reason for hiding this comment

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

Maybe rather than require non-null, if null is passed in just set it to NONE. Be sure to document that though.

*/
public HttpLoggingPolicy(HttpLogDetailLevel detailLevel, boolean prettyPrintJSON) {
this.detailLevel = detailLevel;
public HttpLoggingPolicy(HttpLogOptions httpLogOptions, boolean prettyPrintJSON) {
Copy link
Member

Choose a reason for hiding this comment

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

I'm curious if, outside of unit tests, anyone calls this constructor. If no one does, I would like to see this constructor made package-private for now, because this kind of boolean config should be in the HttpLogOptions object.

//
Mono<Void> reqBodyLoggingMono = Mono.empty();
//
if (detailLevel.shouldLogBody()) {
if (httpLogOptions.getLogLevel().shouldLogBody()) {
Copy link
Member

Choose a reason for hiding this comment

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

Whenever I see a method call (like getLogLevel()) multiple times I prefer to see it referred to in a local variable.

sb.append(REDACTED_PLACEHOLDER);
}
}
logger.info(sb.toString());
Copy link
Member

Choose a reason for hiding this comment

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

Should there be a newline or whitespace included in this concatenation operation?

}
logger.info(sb.toString());
Copy link
Member

Choose a reason for hiding this comment

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

This header concatenation code should be centralised in this class rather than duplicated for request and response headers.

@samvaity samvaity merged commit c0c86cd into Azure:master Oct 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants