[
https://issues.apache.org/jira/browse/SOLR-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17620454#comment-17620454
]
Eric Pugh commented on SOLR-16476:
----------------------------------
i didn't know that we could manipulate the JS on the fly like that, kind of
cool.... Your thinking makes sense to me.
> Don't need commons-text dependency in solr-core
> -----------------------------------------------
>
> Key: SOLR-16476
> URL: https://issues.apache.org/jira/browse/SOLR-16476
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Minor
> Labels: newdev
>
> I don't think we +really+ need commons-text in solr-core. I see it's for
> only one usage:
> https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java#L83
> {noformat}
> String[] search = new String[] {"${contextPath}", "${adminPath}",
> "${version}"};
> String[] replace =
> new String[] {
> StringEscapeUtils.escapeEcmaScript(request.getContextPath()),
>
> StringEscapeUtils.escapeEcmaScript(CommonParams.CORES_HANDLER_PATH),
>
> StringEscapeUtils.escapeEcmaScript(pack.getSpecificationVersion())
> };
> {noformat}
> But contextPath & adminPath are no longer in our admin pages. "version" is.
> Regardless, I don't see why we need to escape EcmaScript; these variables
> come from internal/validated sources that will not have user provided data
> that could hack the pages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
