Member Avatar for mowen85

I have a JSP page with some text boxes. The user fills out the form, clicks the Apply button, the inputs get saved to an Oracle 10.g database. The form can be viewed again and the text boxes are populated with the saved data so the entries can be edited and re-saved.

When reading in from an inputText text box on my JSP page, Oracle stores the < character as &lt;

This means that when the text is retrieved from the database and printed as the value in a JSP inputText box, it is rendered as &lt; instead of <.

The same thing happens with > which gets stored as &gt; but only if one or more < characters are included in the same input text box, otherwise it gets stored in oracle as > and there is no problem retrieving it. No other characters like & or the copyright symbol get converted to their HTML entities, it is just < and >.

Is there a way to stop < and > being converted to their HTML entities when they are saved to the database? When retrieving and displaying, writing a function to examine a string and replace any instances of &lt; with < is not an option because if the string "&lt;" is entered by the user in the text box, I'll want &lt; to be displayed, not <.

Thanks!

  • 2 Contributors
  • 3 Replies
  • 287 Views
  • 6 Days Discussion Span
  • Latest Post Latest Post by ~s.o.s~

Dani AI

Generated

Short diagnosis and the likely cause (based on observations and 's hint): JSF will HTML-encode angle brackets when rendering values into the page. If any code in your submit/validation path HTML-escapes the user input before it is saved (or before it is pushed to the model), that already-escaped text will be escaped again when JSF renders the value attribute — producing visible &amp;lt; in an input box. The correct pattern is to store the raw user text and perform context-appropriate escaping at render time. (docs.oracle.com)

How to confirm where the transformation happens: log the raw request parameters as early as possible and inspect component submitted values during the JSF lifecycle (APPLY_REQUEST_VALUES / PROCESS_VALIDATIONS). Use a PhaseListener (or a simple servlet filter) to print ExternalContext.getRequestParameterMap() and, if needed, check UIInput.getSubmittedValue() for the component. That will tell you whether the browser sent < or the code already changed it. (flylib.com)

Things to search for / common culprits

  • Grep the codebase for HTML-escape calls (StringEscapeUtils.escapeHtml, escapeXml, HtmlUtils.htmlEscape, ESAPI encoder calls, etc.).
  • Inspect any custom validators/converters and check faces-config.xml or tag attributes on the page.
  • If a validator alters the value on failure, it may be the place doing the escaping.
    Quick grep example:
    grep -R -n "escapeHtml\|escapeXml\|StringEscapeUtils\|encodeForHTML\|htmlEscape" .

Fix and best practices

  • Remove any pre-escaping before saving. Persist the raw string.
  • Escape (or sanitize with a whitelist) only when outputting to a particular context (HTML attribute, HTML body, JS, URL). This is the OWASP-recommended approach to avoid double-escaping and to keep stored data canonical. (cheatsheetseries.owasp.org)

Small checklist

  • Log the raw request params (PhaseListener / filter). (flylib.com)
  • If logging shows raw <, find and remove the escape call in your validators/converters.
  • Keep input raw, then let JSF renderers escape for HTML; use h:outputText escape="false" only when you explicitly intend unescaped HTML. (docs.oracle.com)

This isolates the problem quickly: either the browser/transport is fine (it usually is) or some server-side code (validator/converter/filter) is doing the escaping before the model/DB sees it.

Recommended Answers

All 3 Replies

Member Avatar for ~s.o.s~

Have you tried outputting the value in your servlet to see what it is receiving? Form values are submitted as they are; the job of encoding and decoding is automatically performed by your browser unless you are manually submitting the form using Javascript.

Also AFAIK, no database performs automatic conversion to HTML entities. Are you using any external libraries in your project? Anyways, printing the values submitted in a servlet would help us in coming one step closer to the solution.

Member Avatar for mowen85

You're right, it's not happening at the database.

The values from the form fields are of type HtmlInputText, and the conversion from < to &lt; is happening as soon as the form is submitted.

I have some validators on the form, and if one of them fails, all <'s currently in the form text boxes are replaced by &lt;'s when the form is re-displayed for the user to fix the inputs that failed validation.

I know there is an escapeXml="false" attribute you can use for HtmlOutputText, but I can't find anything to stop < being converted to &lt; when using HtmlInputText.

Any ideas?

Member Avatar for ~s.o.s~

I would be assuming that you are using JSF as your UI framework here along with JSP as presentation technology. Even if you are not; the below discussion should be applicable to your problem more or less.

You have an 'escape' attribute for the HtmlOuputText since it's a display only entity and you might want to have complete control over how the data is presented to the client without manually doing the conversion every single time. HtmlInputText doesn't have an 'escape' attribute; actually it shouldn't have an escapeXml attribute since the data entered by the client should reach *as it is* to the server.

That being said, the only problematic area I see is the validation code which automatically converts all the < and > to their HTML Entities. It must be that even when the validation succeeds, the user input is still getting processed and converted to a String having HTML entities in place of < and >.

It might be a good idea to clearly explain your problem than to let the ones helping you out do all the guesswork. You bring up terms like HtmlInputText and validators as if they are commonplace here which isn't the case since they are not part of plain vanilla JSP API. Post the relevant code if you still encounter problems and don't forget to enclose the code in code tags; read the forum announcements regarding that.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.