[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
