[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2019-01-16 Thread JIRA


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

Jan Høydahl commented on SOLR-12194:


This was closed as invalid, so no change in Solr

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2019-01-15 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-12194:
---

[~janhoy] can you write down how it looks when the new API is implemented. I 
just hope it doesn't make it far too unfriendly

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-06-11 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-12194:
-

to clarify: i've never had strong opinions about this, my comments before were 
just to seek clarity on whether this was really moving in the ideal direction 
since it seemed the reverse of one of the intended usecases ... but i don't 
have enough practical experience to know if that even matters -- just wanted to 
make sure it was considered.

since you pinged me though: my only new half thought out comments/questions are 
wether these changes may complicate some of the work miller is doing (or has 
alluded to working on in personal branch i haven't seen) to "modernize" the 
solr client APIs to allow HTTP/2 and true async stuff ... ie: is exposing an 
ability to set arbitrary headers going to be problematic for that? can/should 
we ensure/enforce they are "request level" headers and prevent "connection 
level" headers? (i honestly don't even know which category authorization 
headers fall into ... 

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-06-01 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-12194:


bq. A way to improve this could be for SolrRequest to store a set of generic 
HTTPHeaders instead of basicAuthUser/Pass.  We could provide status utility 
methods to add header for BasicAuth as well as other kinds of headers.

That goes a long way towards my addressing concerns about keeping the API 
intuitive for novice users, especially if a {{setBasicAuthCredentials}} sugar 
method is retained on {{SolrRequest}}.  It also seems to address Hoss's 
concerns about sharing a SolrClient across many users, at least as I understand 
them.  I'll let him speak to that himself though.

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-06-01 Thread JIRA


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

Jan Høydahl commented on SOLR-12194:


[~hossman] & [~gerlowskija] - any further comments? In particular the idea of 
storing HTTPHeaders on SolrRequest instead of basicUser and basicPass?

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-04-10 Thread JIRA

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

Jan Høydahl commented on SOLR-12194:


Or is there a better way we could support any auth scheme on a per-request 
basis through being able to e.g. {{request.setCredentialsProvider(provider)}} 
where Solr will check the request for a provider and use that instead of the 
one configured through the client builder? Have not checked the APIs in detail 
but is the principle worth discussing?

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-04-08 Thread JIRA

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

Jan Høydahl commented on SOLR-12194:


{quote}I'm a little concerned that this API change makes basic-auth setup (a 
pretty commonly used SolrClient feature) more arcane than it needs to be for 
users.
{quote}
I agree that it is much simpler to set username and password on the request 
than to setup a builder. But the current implementation has proven to be buggy 
and difficult to keep up to date, since every possible client request someone 
adds or updates in the future needs to remember to include special basic auth 
handling.
{quote}I thought the entire point of being able to specify credentials on the 
requests was so you could have a client application that used a single client, 
but specified different credentials as needed based on use case – ex: pass 
through credentials from the upstream user?
{quote}
Sure, that's the main benefit, but I have a feeling that majority of apps 
authenticate the *app* with Solr, not individual end *users* per request? For 
that case it is easier to use the builder, and they already can.

Question: If a SolrJ application authenticate/login users with basic auth and 
the application then does a Solr search on behalf of that user, there should be 
no reason for Solr to re-authenticate the end user? What you need is a way to 
pass a pre-authenticated userId down to Solr?

Another question is why Basic Auth should be hardcoded in our clients and 
requests when other (more modern and secure) authentication mechanisms are not 
present, other than through plugins? A way to improve this could be for 
{{SolrRequest}} to store a set of generic HTTPHeaders instead of 
basicAuthUser/Pass. We could provide static utility methods to add header for 
BasicAuth as well as other kind of headers. This would be on a per-request and 
not per-client basis.

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-04-06 Thread Hoss Man (JIRA)

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

Hoss Man commented on SOLR-12194:
-

bq. the only way forward will be using the ClientBuilderFactory.

I thought the entire point of being able to specify credentials on the requests 
was so you could have a client application that used a single client, but 
specified different credentials as needed based on use case -- ex: pass through 
credentials from the upstream user?

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

2018-04-06 Thread Jason Gerlowski (JIRA)

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

Jason Gerlowski commented on SOLR-12194:


1. I'm a little concerned that this API change makes basic-auth setup (a pretty 
commonly used SolrClient feature) more arcane than it needs to be for users.  
Say what you want about the warts surrounding {{set/getBasicAuth*}} but at 
least the methods are easy for novice users to discover and use.  Maybe I'm 
missing some easy way to set up auth and debug it at runtime without these 
getters/setters though.

2. If we're building basic-auth on top of HttpClientBuilderFactory, does it 
make sense to remove the lucene.experimental designation on that interface?

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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