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

Attempt to fix truncated json literals in header values #1638

Closed
wants to merge 5 commits into from

Conversation

sm0217
Copy link

@sm0217 sm0217 commented Jun 24, 2022

Fix for #1464

Attempted a simple fix for the problem where If the value of header, body, queryparam etc starts with {, check if its a json literal before attempting to consider it as an expression.

Assuming unit tests cover all the cases, this fix works as expected for json literals. Need help identifying if this will impact any other expressions.

(Too many file changes because of license header. Changes only in feign core pom, Template and HeaderTemplateTest)

@sm0217 sm0217 marked this pull request as draft June 24, 2022 15:10
@sm0217 sm0217 marked this pull request as ready for review June 24, 2022 15:17
@sm0217
Copy link
Author

sm0217 commented Jun 24, 2022

@velo For #1464

Copy link
Member

@velo velo left a comment

Choose a reason for hiding this comment

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

Sorry mate, we can't have org.json on core.... if that is really need, need to be extracted into a new API and an implementation outside core must be created using org.json, as for core, it must continue clean of dependencies.

@@ -38,6 +38,11 @@
<optional>true</optional>
</dependency>

<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
Copy link
Member

Choose a reason for hiding this comment

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

sorry mate, this is not going to happen.

feign core shall have no dependencies

Copy link
Author

Choose a reason for hiding this comment

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

Alternate would be use regex to validate the json string without any external dependencies. I can already see a feign-json library which uses org.json to encode/decode json. I assume its the right place to add the json literal validation. But we would still need to add the feign-json library into feign-core to use the implementation.

Copy link
Member

@velo velo Jun 28, 2022

Choose a reason for hiding this comment

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

all modules have multiple dependecies.... feign-core does not

But we would still need to add the feign-json library into feign-core to use the implementation

sorry, that won't be approved.

@@ -214,7 +216,7 @@ private void parseFragment(String fragment) {
/* check to see if we have an expression or a literal */
String chunk = tokenizer.next();

if (chunk.startsWith("{")) {
if (chunk.startsWith("{") && !isValidJsonLiteral(fragment)) {
Copy link
Author

Choose a reason for hiding this comment

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

@velo This is the fix I think we need to resolve this issue. Check if the string is a json literal before parsing it as a template. So if you agree with this solution and I have to add this check here, what would be the best approach please? Open for suggestions.

Copy link
Member

Choose a reason for hiding this comment

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

What about the regex option you proposed?

Copy link
Author

@sm0217 sm0217 Jun 28, 2022

Choose a reason for hiding this comment

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

I can try. The regex looks a bit complicated and yet to confirm if it breaks the template string. Let me add that with a few tests and update the PR. However I must add using a library is more elegant and remove complicated stuff under the hood which we don't want to implement ourself.

Copy link
Member

Choose a reason for hiding this comment

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

What if you add a new boolean to @Header(expression = false) default it to true and then change this if to:

if (chunk.startsWith("{") && header.expression()) {

Copy link
Member

Choose a reason for hiding this comment

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

feel free to pick any other name besides expression

Copy link
Member

Choose a reason for hiding this comment

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

I prefer this approach. Let’s add a property to the header annotation indicating that it should be treated like a literal. What about naming the property “literal” and be a Boolean?

Copy link
Member

Choose a reason for hiding this comment

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

It will avoid any regular expressions and simplify the logic to be if “literal” is true, just render otherwise, resolve the expression. There should be a “Literal” type I think in the template package. I think.

Choose a reason for hiding this comment

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

Please remember annotation isn't the only way of setting the header

Copy link
Author

@sm0217 sm0217 Jun 29, 2022

Choose a reason for hiding this comment

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

yes. This will avoid any assumption about the expression/literal.

Copy link
Author

Choose a reason for hiding this comment

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

Although adding a variable like literal in Headers annotation wouldn't always be right since headers values is a string array, it's possible one of header has an expression and one is a literal. A variable would only work out if we can tailor the new variable for every header added to the array. That will be an expensive change.

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.

None yet

4 participants