uschindler commented on code in PR #962:
URL: https://github.com/apache/solr/pull/962#discussion_r951532817
##########
solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java:
##########
@@ -376,10 +377,12 @@ protected long getConfigVersion(SolrCore core) {
*
* @return The loaded {@link ElevationProvider}; not null.
*/
- private ElevationProvider loadElevationProvider(SolrCore core) throws
Exception {
- XmlConfigFile cfg;
+ private ElevationProvider loadElevationProvider(SolrCore core) throws
IOException, SAXException {
+ InputStream inputStream = null;
+ Document xmlDocument;
try {
- cfg = new XmlConfigFile(core.getResourceLoader(), configFileName);
+ inputStream = core.getResourceLoader().openResource(configFileName);
+ xmlDocument = SafeXMLParsing.parseUntrustedXML(log, inputStream);
Review Comment:
> * About modifying XmlConfigFile with `SafeXMLParsing#parseConfigXML`; It
is indeed possible to apply these changes. However, in `XmlConfigFile`, we
authorize the non-availability of SystemId so as not to activate xinclude for
this purpose. Unlike `SafeXMLParsing#parseConfigXML` where we enable it by
default. And, XmlConfigFile is used for reading Solr config files (see
`SolrConfig#readXml`). would that have some impact?
We have a valid system id because the ResourceLoader provides one. XInclude
will then go through SystemIdResolver provided.
> * `SafeXMLParsing#parseConfigXML` enables xinclude by default, whereas
`SafeXMLParsing#parseUntrustedXML` doesn't. It doesn't seem very "safe", is it?
I think if we don't need to activate it we don't have to.
If it is a config file, xinclude should be allowed, as this is the standard
for SOlr config files. There's also no security risk in this because the
xinclude only allows to load files from resource loader and not somewhere
outside (it uses SystemIdResolver to resolve includes, see
https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/util/SystemIdResolver.java#L154-L156).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
