Bug 803115 - Invalid encoding in gadget source not handled properly
Invalid encoding in gadget source not handled properly
Status: MODIFIED
Product: JBoss Enterprise Portal Platform 5
Classification: JBoss
Component: Portal (Show other bugs)
5.2.1.GA
Unspecified Linux
medium Severity medium
: ---
: 5.2.x
Assigned To: Peter Palaga
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-13 21:51 EDT by Miroslav Cupák
Modified: 2018-02-06 14:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: When OpenSocial gadget XML definition had encoding other than the default encoding of the running VM in its XML declaration, an "Unknown error" was presented to the user. Consequence: Gadget was not saved. Fix: The declared encoding is detected, validated and used to store the XML document. Result: An error message is presented to the user only if the XML document contains an unsupported encoding. Otherwise the there is no error message and the document is stored properly.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Commits:
8783 by ppalaga at 2012-07-13 10:36:12 EDT (show)
8783 by ppalaga at 2012-07-13 10:36:12 EDT

Checked in to /mnt/n4aphx2-3.storage.phx2.redhat.com/svn/repos/gatein

Bug 803115 - Invalid encoding in gadget source not handled properly

7 files changed:

  • epp/portal/branches/EPP_5_2_Branch/component/application-registry/src/main/java/org/exoplatform/application/gadget/impl/LocalGadgetData.java (+13 / -5)
  • epp/portal/branches/EPP_5_2_Branch/component/common/src/main/java/org/exoplatform/commons/xml/XMLDeclarationParser.java (+268 / -0)
  • epp/portal/branches/EPP_5_2_Branch/component/common/src/test/java/org/exoplatform/commons/xml/TestXMLDeclarationParser.java (+85 / -0)
  • epp/portal/branches/EPP_5_2_Branch/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIGadgetEditor.java (+38 / -30)
  • epp/portal/branches/EPP_5_2_Branch/portlet/exoadmin/src/main/webapp/WEB-INF/classes/locale/portlet/exoadmin/ApplicationRegistryPortlet_cs.properties (+7 / -6)
  • epp/portal/branches/EPP_5_2_Branch/portlet/exoadmin/src/main/webapp/WEB-INF/classes/locale/portlet/exoadmin/ApplicationRegistryPortlet_de.properties (+8 / -3)
  • epp/portal/branches/EPP_5_2_Branch/portlet/exoadmin/src/main/webapp/WEB-INF/classes/locale/portlet/exoadmin/ApplicationRegistryPortlet_en.properties (+5 / -3)


Attachments (Terms of Use)
Screenshot of the error message. (59.42 KB, image/png)
2012-03-13 21:55 EDT, Miroslav Cupák
no flags Details
Invalid encoding error from the server log. (15.79 KB, text/x-log)
2012-03-13 21:56 EDT, Miroslav Cupák
no flags Details
Invalid prolog content error from the server log. (15.51 KB, text/x-log)
2012-03-13 21:57 EDT, Miroslav Cupák
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker GTNPORTAL-2496 Major Resolved Invalid encoding in gadget source not handled properly 2013-08-19 05:12:21 EDT

  None (edit)
Description Miroslav Cupák 2012-03-13 21:51:51 EDT
Description of problem:
Invalid encoding in gadget source leads to SAXParseException and an "Unknown error" message. The exception should be caught and a proper error message should be displayed.

More specifically, there are two different error messages you can get depending on how you mess up the encoding. You can either run into "org.xml.sax.SAXParseException: Content is not allowed in prolog." (with e.g. "UTF-16" as the encoding) or "org.xml.sax.SAXParseException: Invalid encoding name" (with e.g. "UsadfTF-8" as the encoding).

Steps to Reproduce:
1. Sign in as "root".
2. Go to "Group" > "Administration" > "Application Registry" and switch to "Gadget".
3. Try to create a gadget with an invalid encoding as described above.
Comment 1 Miroslav Cupák 2012-03-13 21:55:06 EDT
Created attachment 569828 [details]
Screenshot of the error message.
Comment 2 Miroslav Cupák 2012-03-13 21:56:12 EDT
Created attachment 569829 [details]
Invalid encoding error from the server log.
Comment 3 Miroslav Cupák 2012-03-13 21:57:11 EDT
Created attachment 569832 [details]
Invalid prolog content error from the server log.
Comment 4 Peter Palaga 2012-07-13 10:54:17 EDT
Fix described inhttps://issues.jboss.org/browse/GTNPORTAL-2496
Comment 5 Peter Palaga 2012-07-13 10:54:17 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: When OpenSocial gadget XML definition had encoding other than the default encoding of the running VM in its XML declaration, an "Unknown error" was presented to the user.
Consequence: Gadget was not saved.
Fix: The declared encoding is detected, validated and used to store the XML document.
Result: An error message is presented to the user only if the XML document contains an unsupported encoding. Otherwise the there is no error message and the document is stored properly.
Comment 6 Miroslav Cupák 2012-08-02 09:58:35 EDT
I verified that nonexistent encoding is handled properly and a proper message is displayed.

However, there seems to be a problem with gadgets using "UTF-16". Such encoding passes validation now and the gadget is saved, but it cannot be displayed by the portal. If you drag it on dashboard, you simply don't see any gadget window on the page, but if you change the encoding and go back to dashboard, the gadget is visible. If the gadget is placed on a portal page (not dashboard), the following JS error is logged: "Uncaught TypeError: Cannot read property 'height' of undefined (merged.js:144)". Observed with a simple "Hello world" gadget.
Comment 7 Thomas Heute 2012-08-09 05:11:18 EDT
AFAIK it is not a regression ? If it's not please target 5.2.x
Comment 8 Peter Palaga 2012-08-09 06:11:24 EDT
@theute: No, this is not a regression. Setting target to 5.2.x.

@mcupak: Thank you for your consequent checks. I could track the problem down to JCR not including the charset in the response's Content-Type. I am going to ask JCR people if that can be fixed.

Note You need to log in before you can comment on or make changes to this bug.