[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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