[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910308#comment-13910308
 ] 

Jan Høydahl edited comment on SOLR-4470 at 2/24/14 2:11 PM:
------------------------------------------------------------

Attaching patch with these changes:

* No whitespace-only diffs.
* AuthCredentials.java moved from {{org.apache.solr.security}} to below 
"common": {{org.apache.solr.common.auth}}, feels it's a better location, 
updated package.html description for the new package
* Javadoc for AuthCredentials class
* CoreAdminRequest#persist() was undeprecated by previous patch, assuming that 
was a typo, re-adding deprecation.
* In previous patch two public static methods in 
CoreAdminRequest#createCore(...) were replaced with methods adding 
AuthCredentials. Added these back not to break back-compat for external users.
* In HttpClientUtil#createClient(...) the code in prev patch was:
 {code}
    if (Boolean.getBoolean( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES) && 
authCredentials != null) {
 {code}
 However, getBoolean on this final string will always be false, changed to what 
I guess was the intention:
 {code}
    if (config.getBool( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES, false) 
&& authCredentials != null) {
 {code}
* In HttpClientUtil, re-add \@Deprecated versions of the old 
PROP_BASIC_AUTH_USER and PROP_BASIC_AUTH_PASS config params along with these
 two method signatures:
  {code}
    public static void configureClient(final DefaultHttpClient httpClient, 
SolrParams config){code}
and
  {code}
    @Deprecated
    public static void setBasicAuth(DefaultHttpClient httpClient, String 
basicAuthUser, String basicAuthPass){code}
  and corresponding code in HttpClientConfigurer. This way 3rd party code 
already using this way will get a warning before they need to recompile in a 
later version of Solr.
  Also added a bullet on top of CHANGES.txt that people should start using the 
new way of doing things. 

Btw. This patch (SOLR-4470.patch) is for r1570335


was (Author: janhoy):
Attaching patch with these changes:

* No whitespace-only diffs.
* AuthCredentials.java moved from {{org.apache.solr.security}} to below 
"common": {{org.apache.solr.common.auth}}, feels it's a better location, 
updated package.html description for the new package
* Javadoc for AuthCredentials class
* CoreAdminRequest#persist() was undeprecated by previous patch, assuming that 
was a typo, re-adding deprecation.
* In previous patch two public static methods in 
CoreAdminRequest#createCore(...) were replaced with methods adding 
AuthCredentials. Added these back not to break back-compat for external users.
* In HttpClientUtil#createClient(...) the code in prev patch was:
 {code}
    if (Boolean.getBoolean( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES) && 
authCredentials != null) {
 {code}
 However, getBoolean on this final string will always be false, changed to what 
I guess was the intention:
 {code}
    if (config.getBool( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES, false) 
&& authCredentials != null) {
 {code}
* In HttpClientUtil, re-add the old PROP_BASIC_AUTH_USER and 
PROP_BASIC_AUTH_PASS config params along with these
 two method signatures:
  {code}
    public static void configureClient(final DefaultHttpClient httpClient, 
SolrParams config){code}
and
  {code}
    public static void setBasicAuth(DefaultHttpClient httpClient, String 
basicAuthUser, String basicAuthPass){code}
  and corresponding code in HttpClientConfigurer. This way 3rd party code 
already using this way will get a warning
  before they need to recompile in a later version of Solr.
  Also added a bullet on top of CHANGES.txt that people should start using the 
new way of doing thigs. 


> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>
>                 Key: SOLR-4470
>                 URL: https://issues.apache.org/jira/browse/SOLR-4470
>             Project: Solr
>          Issue Type: New Feature
>          Components: clients - java, multicore, replication (java), SolrCloud
>    Affects Versions: 4.0
>            Reporter: Per Steffensen
>            Assignee: Jan Høydahl
>              Labels: authentication, https, solrclient, solrcloud, ssl
>             Fix For: 5.0
>
>         Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch, 
> SOLR-4470_trunk_r1568857.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no 
> matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on 
> http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes 
> also make "internal" request to other Solr-nodes, and for it to work 
> credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to 
> all the "internal" sub-requests it triggers. E.g. for search and update 
> request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g. 
> shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g. 
> replica synching stuff)
> We would like to aim at a solution where "original" credentials are 
> "forwarded" when a request directly/synchronously trigger a subrequest, and 
> fallback to a configured "internal credentials" for the 
> asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would 
> like to make a "framework" around it, so that not to much refactoring is 
> needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get 
> input/comments from the community as early as possible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to