Expose a way to log response headers

[dpromanko]

Describe the problem you'd like to have solved

I recently have been going back and fourth on a ticket with support regarding latency we were experiencing. I have been asked on multiple occasions by the support team to provide request ids that come back as a response header x-auth0-requestid. This is frustrating because this SDK does not expose a way to log these.

Describe the ideal solution

For my use case, I think the ideal solution would be to expose a way to add an interceptor to the OkHttp client. This would give consumer access to what they need (headers, etc) without the SDK being opinionated about what it should log and adding something that would need maintained by the SDK over time (the header names changing, etc).

If exposing the ability to add a custom interceptor is too much, it should be enough to expose the log level of the HttpLoggingInterceptor that is added to the OkHttp client today. The SDK sets the log level to Level.NONE currently.

Alternatives and current work-arounds

Additional information, if any

[jimmyjames]

Hi @dpromanko, by default the HttpLoggingInterceptor is set to Level.NONE as you noted. There is the ability to enable it (sets it to Level.BODY), which will include the request, response, and their respective headers, by calling setLoggingEnabled(true) on the API client (obviously care must be taken here as this can include sensitive information):

AuthAPI api = new AuthAPI("domain", "clientId", "clientSecret");
api.setLoggingEnabled(true);

Doing this I verified that calls did log the headers, including the x-auth0-requestid header. Could you try that and let us know if that enables you to get the information you need?

[dpromanko]

@jimmyjames Thanks for the response! I missed this method when I was looking through the sdk. Would it be a consideration to expose that log level further instead of Level.NONE and Level.BODY? It would be nice to be able to log only headers.

[jimmyjames]

@dpromanko yes I think that's a good addition. Also we could expose the ability of the HttpLoggingInterceptor's header redaction, to remove specific sensitive headers from the log.

I'm thinking we could add that additional configurability to the HttpOptions class that can be passed when constructing a new API client, and then deprecate the existing setLoggingEnabled method. Perhaps something like this which would be consistent with our other HTTP configurations:

LoggingOptions loggingOptions = new LoggingOptions(LoggingOptions.LogLevel.HEADERS);
Set<String> headersToRedact = Collections.singleton("Authorization");
loggingOptions.setHeadersToRedact(headersToRedact);
HttpOptions httpOptions = new HttpOptions();
httpOptions.setLoggingOptions(loggingOptions);

ManagementAPI api = new ManagementAPI(DOMAIN, API_TOKEN, httpOptions);
...

Would something like the above work? If so, I can get a PR out and you could take a look if you like. Thanks!

[dpromanko]

@jimmyjames yes that looks like it should give the needed flexibility, especially having redactions exposed as well!

[jimmyjames]

@dpromanko feel free to have a look or try the changes in #392. Thanks!

[dpromanko]

@jimmyjames I tested these changes locally with my application and it functions exactly as I would expect using LogLevel.HEADERS.

[jimmyjames]

The changes in #392 are included in v1.37.0, which will be available in Maven shortly. Thanks for the collaboration on this! 🙇