> -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Tuesday, August 06, 2013 8:52 AM > To: [email protected] > Subject: Re: Making JSON responses html encode field data? > > On 06/08/13 16:11, KARR, DAVID wrote: > >> -----Original Message----- > >> From: Sergey Beryozkin [mailto:[email protected]] > >> Sent: Tuesday, August 06, 2013 2:28 AM > >> To: [email protected] > >> Subject: Re: Making JSON responses html encode field data? > >> > >> Hi > >> On 05/08/13 17:48, KARR, DAVID wrote: > >>> My response controller can send responses in either JSON or XML format, > >> depending on configuration, so I don't have to code any of that. I like > >> that. However, I noticed a difference between the JSON and XML format > that > >> is not surprising on reflection, but which I think I'd now like to > control. > >>> > >>> If I have a piece of data with xml-special characters, like "<" and > others, > >> the XML response properly encodes those characters. The JSON response > does > >> not. This is understandable, because unencoded XML or HTML in a JSON > string > >> is perfectly valid. > >> Looks like that some of the characters may have to be escaped, as > >> opposed to be encoded, > >> http://stackoverflow.com/questions/5417344/json-net-escaping-of-special- > >> characters > >> > >> (also check a link to Mozilla docs at the top) > >>> > >>> The GUI that uses my service is pasting the data into html unchanged. > This > >> appears to occasionally cause rendering problems when the text of some > data > >> fields contain characters that should be encoded in html (there's no > cross- > >> site scripting problem here, it's just an internal monitoring > application). > >>> > >>> I can very easily manually call "StringEscapeUtils.escapeHtml4()" (or > >> perhaps "escapeXml" to be consistent) before I put data into the response, > >> but I was wondering if I could coerce CXF's JSON encoding to encode data > the > >> same way the XML encoding works. Is that possible and reasonable? > >>> > >> Can you please check which characters are causing the issue ? > >> Is it only a double quote '"' and '/' characters ? I've checked > >> JSONProvider - it properly escapes them. > >> > >> Is it some other characters like XML special characters, in addition to > >> '"', which cause the rendering issues ? > >> JSONProvider can be configured to optionally XML-encode those special > >> characters if that can really simplify things > > > > It's the lack of html4 (mostly superset of xml) encoding that is causing > the problem. Storing text with angle brackets, and text within angle > brackets that correspond to html tag names, is what I need to prevent, which > is what html4 encoding does. If I could get it do xml encoding, that would > probably be enough. How do I do that? > > > I guess you can register a custom XMLStreamWriter with JSONProvider, you > can extend JSONProvider#createWriter method and register a custom > implementation, which would look similar to: > > http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/ap > ache/cxf/systest/jaxrs/CustomXmlStreamWriter.java, > except that you will override the methods dealing with characters, example: > > public class MyJSONProvider extends JSONProvider { > > protected XMLStreamWriter createWriter(Object actualObject, Class<?> > actualClass, > Type genericType, String enc, OutputStream os, boolean > isCollection) { > return new MyCustomWriter(super.createWriter(...)); > } > > } > > or may be a simpler option to register it on the message, similar to: > > http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/ap > ache/cxf/systest/jaxrs/XmlStreamWriterProvider.java > > This can be done from a regular CXF interceptor too > > HTH, Sergey
Thanks, but it's looking much easier to just manually call "StringEscapeUtils.escapeHtml4()" on the data I store into my object that is used to form the response. There's only one field that could possibly have html data in it, so I only have to call it once. I was hoping it would be easy to do this globally in the JSONProvider configuration, but that doesn't appear to be the case.
