You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Per Steffensen (JIRA)" <ji...@apache.org> on 2013/05/23 09:36:20 UTC
[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in
internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664953#comment-13664953 ]
Per Steffensen edited comment on SOLR-4470 at 5/23/13 7:35 AM:
---------------------------------------------------------------
Thanks for taking the time to actually understand what this is and is not about, Jan. You clearly did!
In general I do not want to argue too much with you anymore, Mark. You won, but IMHO the community and the project lost. My company and I will act on this "fact", but that is my and my colleagues' problem.
I will try to correct when the truth is not told, though.
bq. it ties Solr further to a webapp and jetty when we are trying to move away from those ties
The solution adds a single line that ties Solr further to webapp - the single line in SolrRequestParsers.parse using createAuthCredentialsFromServletRequest to get the super-request credentials from the javax.servlet.ServletRequest. If some day you move away from being a webapp and use another framework (or your own code) to deal with requests coming from the outside, you will need to extract the credentials in another way. But there is already a million things that need to change in such case - in SolrDispatchFilter, SolrRequestParsers etc. In no other way it ties Solr further to webapp. Everything from that point on is dealt with in Solr code - it is not much and it is nicely isolated.
In no way it ties further to Jetty. Tomcat or Resin or Glassfish or ... will be able to run this code successfully.
bq. it puts us on the line for security, something the project has stayed out of ... I think it should be handled above Solr
That is of course an argument. Personally I do not understand why a serious project would stay out of security, and I do really do not see how security wrt outgoing request can be handled outside Solr itself - in a truly secure way.
was (Author: steff1193):
Thanks for taking the time to actually understand what this is and is not about, Jan. You clearly did!
In general I do not want to argue too much with you anymore, Mark. You won, but IMHO the community and the project lost. My company and I will act on this "fact", but that is my and my colleagues' problem.
I will try to correct when the truth is not told, though.
bq. it ties Solr further to a webapp and jetty when we are trying to move away from those ties
The solution adds a single line that ties Solr further to webapp - the single line in SolrRequestParsers.parse using createAuthCredentialsFromServletRequest to get the super-request credentials from the javax.servlet.ServletRequest. If some day you move away from being a webapp and use another framework (or your own code) to deal with requests coming from the outside, you will need to extract the credentials in another way. But there is already a million things that need to change in such case - in SolrDispatchFilter, SolrRequestParsers etc. In no other way it ties Solr further to webapp. Everything from that point on is dealt with in Solr code - it is not much and it is nicely isolated.
In no way it ties further to Jetty. Tomcat or Resin or Glassfish or ... will be able to run this code successfully.
bq. it puts us on the line for security, something the project has stayed out of ... I think it should be handled above Solr
That is of course an argument. Personally I do not understand why a serious project would stay out of security, and I do really see how security wrt outgoing request can be handled outside Solr itself - in a truly secure way.
> 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: 4.4
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch, SOLR-4470.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org