[
https://issues.apache.org/jira/browse/BATIK-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Bernardo resolved BATIK-1113.
----------------------------------
Resolution: Fixed
> Hard to solve XML External Entities problem
> -------------------------------------------
>
> Key: BATIK-1113
> URL: https://issues.apache.org/jira/browse/BATIK-1113
> Project: Batik
> Issue Type: Bug
> Components: SVG DOM
> Affects Versions: 1.8
> Reporter: Tony BenBrahim
>
> Even if one agrees with the sentiments expressed in the comments of
> BATIK-1018, it should be possible to turn off XML external entity processing
> without subclassing Batik classes.
> Take for example {{SAXSVGDocumentFactory}}, which extends
> {{SAXDocumentFactory}}. When it comes time to parse the SVG in {{Document
> createDocument(InputSource is)}}, line 401 of {{SAXDocumentFacotry}}, the
> code uses either a String classname to instantiate the parser, or an internal
> static factory with package visibility.
> Therefore, the only way to create a parser is to subclass
> {{SAXDocumentFactory}}, override {{createDocument}}, and create your own
> parser, so that it can be configured to not process XEE.
> Any class that parses XML should either:
> - provide a public accessor method to access the default parser factory
> - allow passing in a parser factory
> - allow passing in a parser factory class name (less than ideal, requires
> user to write their own parser factory)
> - allow passing in a parser instance
> In the case of {{SAXDocumentFactory}}, a simple {{public static
> SAXParserFactory getDefaultParserFactory()}} would have obviated the need to
> subclass.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-h...@xmlgraphics.apache.org
