[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662781#comment-13662781
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
Sorry, I didnt follow the discussions on this issue, so that I could have
provided comments sooner. But I kinda gave up on ever getting "more than 10
lines"-patches committed. I would like to help the community though - its not
your fault.
{quote}
I'm very excited for this patch to make it to mainline.
When will this patch be released?
{quote}
Glad to hear that someone out there is using the patch successfully. I would
not expect it to get committed soon - maybe never :-(
{quote}
I will say that passwords in JVM command-lines frighten me, but it is far
better than no auth , and I think this is the best approach for now.
Keep in mind that the Solr Web interface and os-level "ps" commands will
display the entire JVM command line, in this case with password plain text in
JVM command.
I think a credentials in property file would resolve my concerns about the
credentials appearing in JVM command line. I'll see if I can get that to work.
Aside from my passwords-in-commandline concern, I was able to use the patch
without issue at the revision it was made for, although that revision is far in
the past now.
{quote}
The solution provided using JVM parameter to pass credentials is not optimal.
But this is what I thought is generic enough to provide to the community. At my
place we are dealing this this issue though. Clear-text credentials in files
are almost as bad as clear-text credentials in commandline (viewable through
ps-like command), so that was not our solution. We pipe credentials into Solr
using stdin. Then we have a bean in jetty (loaded very early in the startup
sequence) loading credentials from stdin and setting JVM parameters
accordingly. Let me know if you want me to share some code - it very easy to do.
You can protect the Solr Web interface, to that you will have to know the
credentials in order to get access to read them :-)
bq. how about allowing auth user/pass to live in solr.xml/solr.properties and
optionally override with -D flags
This is certainly worth considering. It was in the original thought for the
solution, but it was scoped out in this first go, due to limiting the
extend/size of the patch.
bq. If you're using this patch in test/prod, please report any known issues, so
we can start the push towards getting this committed.
FWIW we are using it in production - no problems.
> 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
