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

Escape JSONP breaking characters #1597

Merged

Conversation

catanm
Copy link
Contributor

@catanm catanm commented Apr 7, 2017

This is a follow-up to this PR: FasterXML/jackson-core#136 from @malaporte.
I ran into the same problem that malaporte had years ago, where the JSONP API response would cause an Uncaught SyntaxError: Invalid or unexpected token when the response contains the characters U+2028 and/or U+2029. It took me quite a bit of time to find the JsonpCharacterEscapes class that he added whose purpose is just to escape those two characters.

I thought it would be nice to incorporate it in the JSONPObject class, since its purpose is just to create a JSONP object.

This is a small change that should make life easier for anyone who is using JSONPObject. Please let me know if you have any questions or would like me to make changes.

@@ -66,6 +66,8 @@ public void serializeWithType(JsonGenerator jgen, SerializerProvider provider, T
public void serialize(JsonGenerator jgen, SerializerProvider provider)
throws IOException, JsonProcessingException
{
// Escape line-separator characters that break JSONP
jgen.setCharacterEscapes(JsonpCharacterEscapes.instance());
Copy link
Member

Choose a reason for hiding this comment

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

This is not safe: generator may have existing escapes user has specified, and this would just replace them.

@cowtowncoder
Copy link
Member

First of all, thank you for submitting this. As per earlier discussions it is an open issue and potential concern.

But this exhibits the same problem as the PR which is not merged: overwriting of character escapes it not something that may be done at low-level code. It is something user controls.
So I am not 100% sure what to do here; one possibility would perhaps be to have a call that temporarily changes things or something.

@catanm
Copy link
Contributor Author

catanm commented Apr 7, 2017

Thanks for replying so promptly. Sorry for not paying enough attention there.

One possibility would be to store the current generator's escapes in a variable as the first thing in the serialize method, then set them to be JsonpCharacterEscapes before all the writes and finally setting them back to the original escapes as the last operation in the method.

A better option would probably be to combine any escapes set by the users with the JsonpCharacterEscapes but I'm not sure that can be done - I can see a straightforward way to get the escape codes for ASCII previously set but not for all the other chars set by overriding public SerializableString getEscapeSequence(int ch).

It seems that the first option is the only feasible one. Also, I feel like overriding the escape chars temporarily to serialize JSONPObject is better than creating an object that doesn't fully comply with the JSONP specification.

What are your thoughts on this?

@cowtowncoder
Copy link
Member

@catanm Another possibility would be to add a new write method that applies escapes for just that call.
Except that I guess that would not work here at all because serialization of value is NOT handled by serializer but via delegation, so it would really have to be change to escaping.

So I guess I am ok with temporary change with reset. One more thought: if there is custom escapes settings in effect, perhaps it should not be changed at all; and only applying escapes if defaults are in use.

Copy link
Contributor Author

@catanm catanm left a comment

Choose a reason for hiding this comment

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

@cowtowncoder I made changes that only apply JSONP-breaking escapes if no custom escapes settings are in place. Escapes are reset as the last operation of the method. Any thoughts?

@catanm
Copy link
Contributor Author

catanm commented Apr 21, 2017

Hi @cowtowncoder - just a nudge to get your thoughts on this.

Thanks!

Marco

@@ -78,6 +88,7 @@ public void serialize(JsonGenerator jgen, SerializerProvider provider)
provider.findTypedValueSerializer(cls, true, null).serialize(_value, jgen, provider);
}
jgen.writeRaw(')');
jgen.setCharacterEscapes(currentCharacterEscapes);
Copy link
Member

Choose a reason for hiding this comment

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

I think this should go in finally block, just in case? Probably not big difference but as a matter of principle.

@cowtowncoder
Copy link
Member

@catanm thanks for the nudge -- I am bit overloaded, so I don't mind reminders.

I think this would do. One last (?) remaining question: have I asked for CLA yet? If not, it's from

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

and usually follows "print, fill & sign, scan, email to info at fasterxml dot com" routine.
If I have asked and received one, no need for another one. Either way, once there is a CLA I'll just go ahead and merge, so it'll make it in 2.9.0.pr3 which I hope to get out by this weekend.

@catanm
Copy link
Contributor Author

catanm commented Apr 21, 2017

@cowtowncoder I wrapped all the jgen.writeRaw calls in a try block and the escapes reset in the finally block. Does it look good to you?

I just sent an email with my CLA attached. Please let me know if you need anything else from me.

One last request: at HubSpot we are on version 2.7.9. Would it be possible for you to backport this fix to that version, along with the JsonpCharacterEscapes changes that this PR depends on (FasterXML/jackson-core#136)?
If you can't I'll just replicate these changes internally until we upgrade to 2.9.

Many thanks,

Marco

@cowtowncoder
Copy link
Member

@catanm I think best chance for backporting would be 2.8(.9). 2.7 is technically still not-closed but release from that is uncertain and will probably take longer. 2.8.9 will be released sooner than that.

@catanm
Copy link
Contributor Author

catanm commented Apr 21, 2017

@cowtowncoder sounds good to me.

Thanks!

Marco

@cowtowncoder cowtowncoder merged commit f3d729a into FasterXML:master Apr 22, 2017
cowtowncoder added a commit that referenced this pull request Apr 22, 2017
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.

2 participants