Skip to content

[undertow] add functions to apply to every marked params in the runtime#255

Merged
bulldozer-bot[bot] merged 31 commits into
palantir:developfrom
rubenfiszel:rf/undertowSafeTags
Apr 9, 2019
Merged

[undertow] add functions to apply to every marked params in the runtime#255
bulldozer-bot[bot] merged 31 commits into
palantir:developfrom
rubenfiszel:rf/undertowSafeTags

Conversation

@rubenfiszel
Copy link
Copy Markdown
Contributor

@rubenfiszel rubenfiszel commented Feb 27, 2019

Before this PR

It is not possible to do any actions on marked params.

After this PR

The runtime include functions that will be called on every marked params. This allow the possibility to to add safe logging among others.

Ruben Fiszel added 2 commits February 27, 2019 16:12
@rubenfiszel rubenfiszel requested a review from a team as a code owner February 27, 2019 16:04
@rubenfiszel rubenfiszel changed the title [WIP][undertow] store safe/unsafe path and query parameters for further processing [undertow] store safe/unsafe path and query parameters for further processing Feb 27, 2019
@rubenfiszel
Copy link
Copy Markdown
Contributor Author

@uschi2000 WC does not support safe body or header parameters. For header parameters it uses a whitelist instead.

@uschi2000
Copy link
Copy Markdown
Contributor

re header & body: what does Conjure support?

@rubenfiszel
Copy link
Copy Markdown
Contributor Author

rubenfiszel commented Feb 27, 2019

@uschi2000 The conjure spec only mentions that they are represented by types in the IR without any requirement for supporting particular ones. I could not find a spec for conjure-java.
So I am assuming the question is: what does the conjure-java-jersey-generator currently support?
Safe markers for header and body are not tested but I modified the tests, and the effect is to write those annotations even for header and body params. But those annotations are without effect when not with our internal webserver library RequestLoggingAnnotationFilter so it is debatable that reaching feature-parity with Jersey is equivalent to also store header and body params.

There is a stronger argument imho which is the one of consistency: All params should be treated the same, as Argument of the endpoints, regardless of their actual wire reification. In that regard, I would agree that we would need to support Header and Body Param (although here we are storing safe and unsafe params, I am not sure we actually want to store heavy body params like binary stream as string attachment key of the exchange).

Nevertheless, my opinion is that it is an under-specified hack that we implement currently to unblock ourselves but without any requirement to do more than what is necessary.
I'm not opposed to storing header params but body params do not make a lot of sense to me. Would that be satisfying? Also the differentiation question now extends to header param as well.

@uschi2000
Copy link
Copy Markdown
Contributor

uschi2000 commented Feb 28, 2019 via email

@uschi2000
Copy link
Copy Markdown
Contributor

uschi2000 commented Feb 28, 2019 via email

@rubenfiszel
Copy link
Copy Markdown
Contributor Author

rubenfiszel commented Feb 28, 2019

@uschi2000 Latest commit now only use 2 multimaps, one for safe and one for unsafe params. It supports header params and some docs has been added. It now filters on "Safe" name.

Copy link
Copy Markdown
Contributor

@uschi2000 uschi2000 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 modulo a few nitpicks

@carterkozak
Copy link
Copy Markdown
Contributor

carterkozak commented Feb 28, 2019 via email

@rubenfiszel
Copy link
Copy Markdown
Contributor Author

@cakofony ofc!

@rubenfiszel rubenfiszel changed the title [undertow] store safe parameters for further processing [undertow] add functions to apply to every marked params in the runtime Apr 8, 2019

/** Provides the {@link MarkedParam} used to store safe parameters (header, query, body params) for further
* processing. (e.g logging) */
MarkedParam markedParam();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That makes sense, though I think it may be cleaner to leave mark as is since marking other types of data would use a different method signature. I don't have a strong opinion, markParam is also reasonable.

Comment thread conjure-java-core/src/test/resources/example-service.yml
@carterkozak
Copy link
Copy Markdown
Contributor

I like the simplicity of this approach. It doesn't force special-case code specifically for safe/unsafe parameters and maintains the same level of separation we've had in the jersey implementation.

@carterkozak
Copy link
Copy Markdown
Contributor

I'm happy with this. Any thoughts before it merges @iamdanfox @uschi2000?

@uschi2000
Copy link
Copy Markdown
Contributor

uschi2000 commented Apr 9, 2019 via email

…ices/JerseyServiceGenerator.java

Co-Authored-By: rubenfiszel <rubenfiszel@gmail.com>
ResourceIdentifier datasetRid =
runtime.plainSerDe().deserializeRid(pathParams.get("datasetRid"));
runtime.markers()
.param("com.palantir.redaction.Safe", "datasetRid", datasetRid, exchange);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

👍 this is really nice, really like how it doesn't back us into a corner in terms of future development :)

Copy link
Copy Markdown
Contributor

@iamdanfox iamdanfox left a comment

Choose a reason for hiding this comment

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

Looks great to me!

@bulldozer-bot bulldozer-bot Bot merged commit b5fef18 into palantir:develop Apr 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants