[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585088#comment-13585088
]
Per Steffensen edited comment on SOLR-4470 at 2/23/13 11:08 AM:
----------------------------------------------------------------
Well I developed first and foremost to be used internally by my organization,
so I developed on top of an internal 4.0.0+ version (the + being modifications
we have not gotten committed yet - it is hard to get cool stuff committed if it
involves a lot of changes - SOLR-3178). You will probably not be able to use a
patch made from there. Therefore I need to move changes to a clean Apache
revision/branch anyway, and that is where you could have some influence on the
choice. I will go for 4.x branch.
I would like to introduce a few new sayings
* Patches in Jira fitting on top for recent revisions are better than patches
in Jira fitting on top of old revisions - commit it while its hot
* Projects where you trust your test-suite enough to dare do major refactoring,
are the only projects you can keep building on for a long time
* When introducing new feature, any developer should see it as his duty to do
refactoring to make the code seem as if the new feature was thought into the
product from the beginning
was (Author: steff1193):
Well I developed first and foremost to be used internally by my
organization, so I developed on top of an internal 4.0.0+ version (the + being
modifications we have not gotten committed yet - it is hard to get cool stuff
committed if it involves a lot of changes - SOLR-3178). You will probably not
be able to use a patch made from there. Therefore I need to move changes to a
clean Apache revision/branch anyway, and that is where you could have some
influence on the choice. I will go for 4.x branch.
I would like to introduce a few new sayings
* Patches in Jira fitting on top for recent revisions are better than patches
in Jira fitting on top of old revisions - commit it while its hot
* Projects where you trust your test-suite enough to dare do major refactoring,
are the only projects you can keep building on for a long time
> 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: Bug
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Labels: authentication, solrclient, solrcloud
> Fix For: 4.2
>
>
> 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
