[
https://issues.apache.org/jira/browse/SOLR-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15209048#comment-15209048
]
Noble Paul commented on SOLR-8887:
----------------------------------
writers of a security plugin will face this problem, but general users of
security would not have any backcompat issues. It is trivial for BasicAuth to
get rid of this dependency. However, Kerberos will have a problem.
I propose the following
* The public API should rely on another class and it should not have any
deprecated stuff. So , PKIAuth and BasicAUth can start using that API right away
* Kerberos support can rely on deprecated class for the time being , and we can
limit the damage
* Eventually we will need to reimplement Kerberos without relying on the
deprecated classes
> Solr Security features cannot export the internal, deprecated
> DefaultHttpClient class as part of their user facing API.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8887
> URL: https://issues.apache.org/jira/browse/SOLR-8887
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> Priority: Critical
> Fix For: master
>
>
> Seems security now really depends on HttpClientConfigurer. That class was
> only used for tests previously, and was at best completely unsupported. We
> can't promise an API that locks us into an internal, low level, class from a
> lib. Especially a deprecated one. Solr wants to own the http layer, not get
> locked into impls.
> We need to stop using DefaultHttpClient, and it's going to break this stuff.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
