Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add filter query string option #29

Merged
merged 3 commits into from
Mar 8, 2018

Conversation

pmensik
Copy link
Contributor

@pmensik pmensik commented Mar 1, 2018

I've added an option to disable query string logging based on #27 issue. Please feel free to review it and suggest enhancements. Best regards, Petr

(if (and query-string
(:log-query-string? options))
(str uri "?" query-string)
uri)
Copy link
Owner

Choose a reason for hiding this comment

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

A minor thing: As we are here, could you please extract uri out from the conditional into a separate line, and change the conditional to something like

(when (and query-string (:log-query-string? options)
   (str "?" query-string))`

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, changed it :)

:server-port
:uri]]
(debug logger (str "Request details: " (select-keys req (if log-query-string?
default-keys
Copy link
Owner

Choose a reason for hiding this comment

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

Another minor thing:

I think it would read slightly better to remove query-string from default-keys and then invert this conditional to conj default-keys :query-string

But I'm fine if you prefer to keep it this way :)

Copy link
Owner

Choose a reason for hiding this comment

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

Also, I think the debug is missing some indentation, it seems to be at the same level as the let that wraps it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I've decided to replace it with cond->, seems to me both more flexible and readable, I hope you are ok with that.

Copy link
Owner

Choose a reason for hiding this comment

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

I also like the cond-> better, thanks!

(if (and query-string
(:log-query-string? options))
(str uri "?" query-string)
uri)
Copy link
Owner

Choose a reason for hiding this comment

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

same thing about extracting uri and turn if into when

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@@ -123,6 +123,20 @@
(->> (map #(nth % 3) @*entries*)
(filter #(re-find #"secret" %)))))))

(deftest basic-ok-request-logging-without-query-params
Copy link
Owner

Choose a reason for hiding this comment

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

Thanks for adding this test!

I don't think we are testing the opposite (and default) case where query-string is logged anywhere else. It would be great if you could add a test to show that query string is logged out when log-query-string? is not set (so it takes the default value). It could have a param from the set of redact-keys, like password for example, to show it goes through unredacted

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added new test which covers default settings (log-query-string? not being set)

@nberger
Copy link
Owner

nberger commented Mar 6, 2018

@pmensik thanks for your contribution! I took some time to respond because I'm thinking what direction should the library take, but I think this change is a nice thing to add: if we provide a redact mechanism, we shouldn't log the query params unredacted, without a mechanism to avoid it.

I added some comments, I'll wait for your response before merging and making a new release.

I'll post an issue soon with my thoughts about the next steps for the library, and this will probably be the last addition (except for bug fixes) on the 0.7.x series. Main idea will be to to make the core messages more minimalist and probably make them be simple maps, with an output-fn to give the chance to transform the maps into whatever format and do the actual logging. Anyways, don't want to add more noise here, I'll post more details on a separate issue!

@nberger nberger added the 0.7.x label Mar 6, 2018
@nberger nberger merged commit c724768 into nberger:master Mar 8, 2018
@nberger
Copy link
Owner

nberger commented Mar 8, 2018

Thanks @pmensik. I'll cut a release later today

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants