subject:"\[jira\] \[Comment Edited\] $SOLR\-4470$ Support for basic http auth in internal solr requests"

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2015-01-05 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264463#comment-14264463
]

Per Steffensen edited comment on SOLR-4470 at 1/5/15 10:28 AM:
---

There is a variant of 2nd suggestion, that I just want to mention briefly (I am
not good at being brief) - something that we do of other reasons. You might
want to divide your set of Solr-nodes into two sub-sets
* Search-Solrs: Receiving incoming search requests from outside clients. Not
containing any data themselves but orchestrating the distributed searches
against the Data-Solrs
* Data-Solrs: Not directly accessible (network-wise) to outside clients
Setting up web-container security on Search-Solrs only might work, because they
do not have to communicate with each other. And it might be enough for you if
Data-Solrs are not accessible from outside.
We have such a setup but not for security reasons - we have web-container
security on both Search-Solrs and Data-Solrs. Just wanted to mention it because
it also might make things easier for you, and since I know it is possible this
is also an option for you. We do the separation because of different hardware
requirements for the two kinds of Solr-nodes. Search-Solrs need more memory but
almost no disk-space, Data-Solrs need more disk-space but less memory - in our
setup, with the amounts and distribution of data we have and for the searches
we perform against the Sor-cluster.

Technically what we do is that we make a search-collection containing no
data. search-collection only has shards on the Search-Solrs. Then we have
several data-collections (containing the data) only having shards on the
Data-Solrs. We have custom (not much code) SearchHandler/SearchComponents (Solr
concepts) that basically just calculates the data-collection you have to
search and forwards the search from outside clients to search-collection to
those data-collections. We have an advanced algorithm for calculating the
data-collections that has to be searches given the concrete search to
search-collection, but you can just always calculate all data-collections.
This way Search-Solrs handle the distributed search, while Data-Solrs handle
searches against local shard only. This is kinda the same as putting your own
custom gateway in front of your Solr-nodes, and make the Solrs-nodes
inaccessible directly from outside clients. We just use Solr itself as this
front gateway, taking advantage of all the nice features - high availability
(with more than one Search-Solr) etc.

Clients uses CloudSolrServer, but always make searches against the
search-collection.

was (Author: steff1193):
There is a variant of 2nd suggestion, that I just want to mention briefly (I am
not at being brief) - something that we do of other reasons. You might want to
divide your set of Solr-nodes into two sub-sets
* Search-Solrs: Receiving incoming search requests from outside clients. Not
containing any data themselves but orchestrating the distributed searches
against the Data-Solrs
* Data-Solrs: Not directly accessible (network-wise) to outside clients
Setting up web-container security on Search-Solrs only might work, because they
do not have to communicate with each other. And it might be enough for you if
Data-Solrs are not accessible from outside.
We have such a setup but not for security reasons - we have web-container
security on both Search-Solrs and Data-Solrs. Just wanted to mention it because
it also might make things easier for you, and since I know it is possible this
is also an option for you. We do the separation because of different hardware
requirements for the two kinds of Solr-nodes. Search-Solrs need more memory but
almost no disk-space, Data-Solrs need more disk-space but less memory - in our
setup, with the amounts and distribution of data we have and for the searches
we perform against the Sor-cluster.

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2015-01-05 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264463#comment-14264463
]

Per Steffensen edited comment on SOLR-4470 at 1/5/15 10:29 AM:
---

Setting up web-container security on Search-Solrs only might work, because they
do not have to communicate with each other. And it might be enough for you if
Data-Solrs are not accessible from outside.
We have such a setup but not for security reasons - we have web-container
security on both Search-Solrs and Data-Solrs. Just wanted to mention it because
it also might make things easier for you, and since I know it is possible this
is also an option for you. We do the separation because of different hardware
requirements for the two kinds of Solr-nodes. Search-Solrs need more memory but
almost no disk-space, Data-Solrs need more disk-space but less memory - in our
setup, with the amounts and distribution of data we have and for the searches
we perform against the Sor-cluster.

Clients uses CloudSolrServer, but always make searches against the
search-collection.

was (Author: steff1193):
There is a variant of 2nd suggestion, that I just want to mention briefly (I am
not good at being brief) - something that we do of other reasons. You might
want to divide your set of Solr-nodes into two sub-sets
* Search-Solrs: Receiving incoming search requests from outside clients. Not
containing any data themselves but orchestrating the distributed searches
against the Data-Solrs
* Data-Solrs: Not directly accessible (network-wise) to outside clients
Setting up web-container security on Search-Solrs only might work, because they
do not have to communicate with each other. And it might be enough for you if
Data-Solrs are not accessible from outside.
We have such a setup but not for security reasons - we have web-container
security on both Search-Solrs and Data-Solrs. Just wanted to mention it because
it also might make things easier for you, and since I know it is possible this
is also an option for you. We do the separation because of different hardware
requirements for the two kinds of Solr-nodes. Search-Solrs need more memory but
almost no disk-space, Data-Solrs need more disk-space but less memory - in our
setup, with the amounts and distribution of data we have and for the searches
we perform against the Sor-cluster.

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-12-04 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234548#comment-14234548
]

Per Steffensen edited comment on SOLR-4470 at 12/4/14 7:56 PM:
---

Thanks for participating [~zoomieia1980]!!!

I am not sure you really understand what my patch is about. It ONLY deals with
adding credentials to outgoing requests in order to be able to penetrate a
security-layer on the server-side. This is necessary if you choose to somehow
put a security-layer between the Solr client and the Solr server. This patch
has NOTHING to do with setting up that security-layer around the server.
Webcontainers do that very well for you. And if Solr really want to move away
from being a webapplication that has to run in a webcontainer, there are
numerous other frameworks out there that you can use to set up a security-layer
around your server. But this patch has nothing to do with how you add that
security-layer around your server. You keep talking about JAAS LoginModules
etc. and they really are concepts belonging in this security-layer around the
server - thats why I believe you do not completely follow my patch.

Changing the SolrJ client so that it adds hardcoded credentials to all
outgoing requests is really just a few lines around the HTTPClient-usage that
you talk about. In this area, my patch really is not more than those few lines,
except that I support doing it at several levels
* Setting up the credentials once and for all on HTTPClient level, so that it
will add those credentials to all requests sent through it
* Doing the same on SolrJ XXXSolrServer (clients) level - basically doing it on
the HTTPClients of the HTTPSolrServers used directly or underneath more
complicated XXXSolrServers like CloudSolrServer
* It also supports setting credentials on request-level, allowing you to use
different credentials for different requests sent through the same HTTPClient,
without having to change the global credentials on HTTPClient level

But all of this is not that many lines of code

The thing is, that in a Cloud setup, the Solr server itself is a Solr client,
sending requests to other Solr servers. If there is a security-layer between
the Solr servers (and there will be if you use e.g. webcontainer managed
security) you need to somehow tell the Solr servers which credentials to add to
its outgoing requests targeting other Solr servers. My patch is a lot about
this aspect. You can fairly easily make in a way so that it just always uses
the same hardcoded credentials on those outgoing requests. But you might want
to configure those fixed credentials from the outside. What if you actually
want to use different credentials depending on the kind of the outgoing
request. What if the outgoing request is actually triggered from an incoming
request, do you want to use the credentials from the ingoing request on the
outgoing request? E.g. if an outside client sends a distributed query R1 to
Solr server A, Solr server A has to send sub-requests R2 to Solr server B -
should it copy the credentials from R1 to R2 or should it use
configured/hardcoded credentials for R2?
You might have very different algorithms for Solr servers to decide on
credentials for the requests it sends to other Solr servers. In some cases the
Solr server might need to fetch the credentials from an outside agency, or you
might have a handshake/negotiating-step (like SOLR-6625) or something. Most of
the non-test-code in my patch is about making the component that calculates
credentials for requests going out of Solr servers pluggable.

But most of the patch is actually test-code. I tend to want to test my stuff
thoroughly. In Solr tests we start actual Solr servers sending real requests to
each other. So why not test this entire thing by setting up webcontainer
managed security in the embedded jetty-containers running the Solr servers in
test. Some of the code joggles those things.

was (Author: steff1193):
Thanks for participating [~zoomieia1980]!!!

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-03-31 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13955165#comment-13955165
]

Per Steffensen edited comment on SOLR-4470 at 3/31/14 1:37 PM:
---

bq. Do we really need to pass credentials around everywhere?

They really are not passed around

bq. What David Webster described sounds like a much cleaner approach?

Do you really think so!?! IMHO it sounds much more complicated. The patch to
SOLR-4470 is really very simple with respect to changes in non-test code, it
will make it very easy to setup addition of credentials to outgoing requests,
it does not require any other components than Solr running in your
infrastructure and it will not require include and config of any 3rd-party
libraries.

bq. The problem is on the Sending side (client)

This patch only deals with the sending side. With respect to doing the actual
authentication and authorization of ingoing requests it is not handled by Solr
(and probably shouldnt). As long as we run in a servlet-container (e.g. Tomcat,
but also all other certified servlet-containers) you can set up you security in
web.xml and use common LoginModules (or customize your own if you want to).

bq. That involved four lines of code in the actual SOLR code ...

This patch is not much more than those four lines, except that we support
setting up credentials in solr.xml and to calculate credentials given the
super-request. Besides that just thorough testing.

bq. Now, if they ever move SOLR out of the Servlet container into a stand alone
implementation.we have a problem with our approach, and have to take this
patch's full approach.

If they move Solr out of the servlet-container hopefully they support some
other way of setting up protection against ingoing requests. But this patch
will not help you. This issue is only about adding credentials to outgoing
requests.

was (Author: steff1193):
bq. Do we really need to pass credentials around everywhere?

They really are not passed around

bq. What David Webster described sounds like a much cleaner approach?

Do you really think so!?! IMHO it sounds much more complicated. The patch to
SOLR-4470 is really very simple with respect to changes in non-test code, it
will make it very easy to setup addition of credentials to outgoing requests,
it does not require any other components then Solr running in your
infrastructure and it will not require include and config of any 3rd-party
libraries.

bq. The problem is on the Sending side (client)

bq. That involved four lines of code in the actual SOLR code ...

This patch is not much more than those four lines, except that we support
setting up credentials in solr.xml and to calculate credentials given the
super-request. Besides that just thorough testing.

bq. Now, if they ever move SOLR out of the Servlet container into a stand alone
implementation.we have a problem with our approach, and have to take this
patch's full approach.

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: 5.0

Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470_trunk_r1568857.patch

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-03-25 Thread David Webster (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947430#comment-13947430
]

David Webster edited comment on SOLR-4470 at 3/26/14 1:29 AM:
--

We took advantage of the fact that SOLR is deployed to Tomcat. Tomcat, being
the reference implementation of the servlet standard means you can use JAAS
LoginModules, which essentially intercept the request stream before it even
gets to the application layer, and exercise authtentication and provide
authorization tokens for use in the app layer. That's what we did. The
problem is on the Sending side (client). There, actual core code has to be
altered to either add existing auth into the stream or perform auth then add it
to the stream. That involved four lines of code in the actual SOLR code,
couple with a custom auth jar we bind into the WAR.

Now, if they ever move SOLR out of the Servlet container into a stand alone
implementation.we have a problem with our approach, and have to take this
patch's full approach.

was (Author: zoomieia1980):
We took advantage of the fact that SOLR is deployed to Tomcat. Tomcat, being
the reference implementation of the servlet standard means you can use JAAS
LoginModules, which essentially intercept the request stream before it even
gets to the application layer, and exercise authtentication and provide
authorization tokens for use in th

Support for basic http auth in internal solr requests
-

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 was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-03-13 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933081#comment-13933081
 ] 

Jan Høydahl edited comment on SOLR-4470 at 3/13/14 11:45 AM:
-

bq. Guess this should not be a TODO here since we're inside the SysProp impl

I moved the meat of the comment as a JavaDoc on the class itself.

bq. I found no way to test if a Set is unmodifiable

Try to modify it and catch UnsupportedOperationException :-) However I find no 
harm in always wrapping, so I'll just remove the TODO.

bq. Thread.sleep(1);

Since collection API since SOLR-4577 already waits for completion, the 10s 
sleep can go away right away, and when SOLR-5853 is done, we can also do an 
extra assert on the response.

*Comments wanted*

Any comments on the {{doAndAssertSolrExeption(-1 /*403*/...}} part or the dead 
code snippet?

Other changes I'm doing in the next version of the patch:
* Moving the solr.xml factory-class config from 
{{solr/security/insanely-long-and-complicated-tagname/xxxRequest...}} to: 
{{solr/authentication/subRequestFactory/str\[@name='class'\]}}, this way it is 
possible to remember the path :-) *Edit: keep it on top level since auth may be 
wanted outside of solrcloud as well, e.g. replicationHandler* 
* Simplifying the basic auth sysProperty names from 
{{internalAuthCredentialsBasicAuthUsername}} and 
{{internalAuthCredentialsBasicAuthPassword}} to {{solr.auth.user}} and 
{{solr.auth.pass}}
* Randomizing BaseDistributedSearchTestCase.RUN_WITH_COMMON_SECURITY in 
\@BeforeClass, but it will of course still always be active for the tests in 
SecurityDistributedTest


was (Author: janhoy):
bq. Guess this should not be a TODO here since we're inside the SysProp impl

I moved the meat of the comment as a JavaDoc on the class itself.

bq. I found no way to test if a Set is unmodifiable

Try to modify it and catch UnsupportedOperationException :-) However I find no 
harm in always wrapping, so I'll just remove the TODO.

bq. Thread.sleep(1);

Since collection API since SOLR-4577 already waits for completion, the 10s 
sleep can go away right away, and when SOLR-5853 is done, we can also do an 
extra assert on the response.

*Comments wanted*

Any comments on the {{doAndAssertSolrExeption(-1 /*403*/...}} part or the dead 
code snippet?

Other changes I'm doing in the next version of the patch:
* Moving the solr.xml factory-class config from 
{{solr/security/insanely-long-and-complicated-tagname/xxxRequest...}} to below 
solrcloud: {{solr/solrcloud/auth/subRequestFactory/str\[@name='class'\]}}, this 
way it is possible to remember the path :-)
* Simplifying the basic auth sysProperty names from 
{{internalAuthCredentialsBasicAuthUsername}} and 
{{internalAuthCredentialsBasicAuthPassword}} to {{solr.auth.user}} and 
{{solr.auth.pass}}
* Randomizing BaseDistributedSearchTestCase.RUN_WITH_COMMON_SECURITY in 
\@BeforeClass, but it will of course still always be active for the tests in 
SecurityDistributedTest

 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: 5.0

 Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, 
 SOLR-4470_trunk_r1568857.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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-03-12 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931530#comment-13931530
 ] 

Jan Høydahl edited comment on SOLR-4470 at 3/12/14 11:49 AM:
-

([~steff1193] I did not complete my comment earlier)

Checking *TODO*s in the patch

h3. In SystemPropertiesAuthCredentialsInternalRequestFactory

bq. TODO since internalAuthCredentials is something you use for internal 
requests against other Solr-nodes it should never have different values for 
different Solr-nodes in the same cluster, and therefore the credentials ought 
to be specified on a global level (e.g. in ZK) instead of on a per node level 
as VM-params are

Guess this should not be a TODO here since we're inside the SysProp impl, but 
rather open a JIRA for a ZK auth cred impl once this gets in

h3. In SecurityDistributedTest:

{code}
// TODO It ought to have been 403 below instead of -1, but things are just 
crappy with respect to 403 handling around the code
doAndAssertSolrExeption(-1 /*403*/, new CallableObject() {
{code}

Do you remember why you put this comment instead of cleaning up the code?

{code}
/* TODO Seems like the single control-node is sending requests to itself in 
order to handle get!?
  controlClient.query(params, METHOD.GET, SEARCH_CREDENTIALS);*/
{code}

Dead code, better remove it, or is there something to clarify?

{code}
// TODO: REMOVE THIS SLEEP WHEN WE HAVE COLLECTION API RESPONSES
Thread.sleep(1);
{code}

There is SOLR-4577 which seems to be fixed already, can we perhaps spin off 
another JIRA to add a return status from 
{{AbstractFullDistribZkTestBase#createCollection()}} and friends. That way we 
can avoid adding another 10s of sleep through this test

h3. In AuthCredentials

{code}
// TODO we ought to test if authMethods is already unmodifiable and not wrap it 
if it is, but I hope/guess
// Collections.unmodifiableSet will do that internally - I found no way to test 
if a Set is unmodifiable
this.authMethods = Collections.unmodifiableSet(authMethods);
{code}

Anyone who *knows* if this is safe? If so better remove the whole TODO


was (Author: janhoy):
There's a TODO in SystemPropertiesAuthCredentialsInternalRequestFactory
{blockquote}
TODO since internalAuthCredentials is something you use for internal requests 
against other Solr-nodes it should never
have different values for different Solr-nodes in the same cluster, and 
therefore the credentials ought to be specified
on a global level (e.g. in ZK) instead of on a per node level as VM-params are
{blockquote}

 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: 5.0

 Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, 
 SOLR-4470_trunk_r1568857.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 was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-03-12 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931674#comment-13931674
]

Jan Høydahl edited comment on SOLR-4470 at 3/12/14 3:02 PM:

I think at least we should fix the sleep(1) as a separate JIRA *before*
committing this patch.
Created SOLR-5853 for this.

was (Author: janhoy):
I think at least we should fix the sleep(1) as a separate JIRA *before*
committing this patch.

Support for basic http auth in internal solr requests
-

Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470_trunk_r1568857.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-02-24 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910308#comment-13910308
 ] 

Jan Høydahl edited comment on SOLR-4470 at 2/24/14 2:11 PM:


Attaching patch with these changes:

* No whitespace-only diffs.
* AuthCredentials.java moved from {{org.apache.solr.security}} to below 
common: {{org.apache.solr.common.auth}}, feels it's a better location, 
updated package.html description for the new package
* Javadoc for AuthCredentials class
* CoreAdminRequest#persist() was undeprecated by previous patch, assuming that 
was a typo, re-adding deprecation.
* In previous patch two public static methods in 
CoreAdminRequest#createCore(...) were replaced with methods adding 
AuthCredentials. Added these back not to break back-compat for external users.
* In HttpClientUtil#createClient(...) the code in prev patch was:
 {code}
if (Boolean.getBoolean( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES)  
authCredentials != null) {
 {code}
 However, getBoolean on this final string will always be false, changed to what 
I guess was the intention:
 {code}
if (config.getBool( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES, false) 
 authCredentials != null) {
 {code}
* In HttpClientUtil, re-add \@Deprecated versions of the old 
PROP_BASIC_AUTH_USER and PROP_BASIC_AUTH_PASS config params along with these
 two method signatures:
  {code}
public static void configureClient(final DefaultHttpClient httpClient, 
SolrParams config){code}
and
  {code}
@Deprecated
public static void setBasicAuth(DefaultHttpClient httpClient, String 
basicAuthUser, String basicAuthPass){code}
  and corresponding code in HttpClientConfigurer. This way 3rd party code 
already using this way will get a warning before they need to recompile in a 
later version of Solr.
  Also added a bullet on top of CHANGES.txt that people should start using the 
new way of doing things. 

Btw. This patch (SOLR-4470.patch) is for r1570335


was (Author: janhoy):
Attaching patch with these changes:

* No whitespace-only diffs.
* AuthCredentials.java moved from {{org.apache.solr.security}} to below 
common: {{org.apache.solr.common.auth}}, feels it's a better location, 
updated package.html description for the new package
* Javadoc for AuthCredentials class
* CoreAdminRequest#persist() was undeprecated by previous patch, assuming that 
was a typo, re-adding deprecation.
* In previous patch two public static methods in 
CoreAdminRequest#createCore(...) were replaced with methods adding 
AuthCredentials. Added these back not to break back-compat for external users.
* In HttpClientUtil#createClient(...) the code in prev patch was:
 {code}
if (Boolean.getBoolean( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES)  
authCredentials != null) {
 {code}
 However, getBoolean on this final string will always be false, changed to what 
I guess was the intention:
 {code}
if (config.getBool( HTTP_CLIENTS_MUST_ADAPT_TO_CREDENTIALS_CHANGES, false) 
 authCredentials != null) {
 {code}
* In HttpClientUtil, re-add the old PROP_BASIC_AUTH_USER and 
PROP_BASIC_AUTH_PASS config params along with these
 two method signatures:
  {code}
public static void configureClient(final DefaultHttpClient httpClient, 
SolrParams config){code}
and
  {code}
public static void setBasicAuth(DefaultHttpClient httpClient, String 
basicAuthUser, String basicAuthPass){code}
  and corresponding code in HttpClientConfigurer. This way 3rd party code 
already using this way will get a warning
  before they need to recompile in a later version of Solr.
  Also added a bullet on top of CHANGES.txt that people should start using the 
new way of doing thigs. 


 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: 5.0

 Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, 
 SOLR-4470_trunk_r1568857.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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2014-01-27 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883290#comment-13883290
]

Per Steffensen edited comment on SOLR-4470 at 1/27/14 9:09 PM:
---

bq. This product does not, and even worse, the core Dev team seems intent on
NEVER doing so!

At least most of them, yes. It is really a shame.

bq. As the lead Java architect for Distributed Systems Engineering at a fortune
100 company, security is my single most important concern

As the tech lead on the largest REAL SolrCloud installation on the planet, I
agree :-) I believe I can say that we have the largest installation in the
world for two reasons
* Upgrading from one version of SolrCloud to the next is not something that
seem to be very important in this product. At least it is hard to do, and there
seem to be no testing of it when a new release 4.y comes out - no testing that
you can actually upgrade to it from 4.x. This makes me believe that no-one or
at least only a few, have so big installations that just installing 4.y and
store/index all data from the old 4.x installation from scratch is not an
option. If others actually had to do upgrades where this is not possible, lots
of complaints would pop up - and they dont
* Our biggest system stores and indexes 1-2 billion documents per day, and have
2 years of history. That is about 1000 billion documents in Solr at any time
with 1-2 billion going in every day (and 30-60 billion going out every month).
To be able to run such a system we needed to do numerous optimizations, and in
general without optimizations you will never get such a big system working. I
do not see much talk around here about optimizations of that kind - probably
because people have not run into the problems yet.

bq. I like Solr. I like what it does and how it does it.

Me too. On that part it actually has numerous advantages over e.g.
ElasticSearch. We used ES to begin with, and we liked it, but for political
reasons we where not allowed to keep using it, and we turned to find an
alternative. At that point in time SolrCloud (4.x) where only in its startup
phase (a year before 4.0 was released), but we believed so much in the idea
behind, that we decided to go for it.

bq. However, it's lack of internal security hooks is a complete show stopper
for use at my firm

For us, too. That is why we made our own fix to it - provided as a patch here
and also available at https://github.com/steff1193/lucene-solr

bq. Using this patch as our starting point

I am happy to hear that. Please feel free to contact me if you have any
problems making it work or understanding what it does. I might also be able to
provide a few tips on making it extra secure :-)

bq. and have our own Solr-like engine

We made the same decision years ago. We have had our own version of Solr in our
own VCS for years. Just recently I put the code on
https://github.com/steff1193/lucene-solr. No releases (incl maven artifacts)
yet. But that will come soon. Until then you will have to build it yourself
from source.

bq. Also, Mavenize the damned thing! Modern projects still use Ant? I haven't
opened a build.xml script in half a decade or more

Already done.
{code}
ant [-Dversion=$VERSION] get-maven-poms
{code}
Will build the maven structure in folder maven-build
E.g. if you use Eclipse
{code}
ant eclipse
{code}
In Eclipse right-click the root-folder, chose Import... and Existing Maven
Project. Import all Maven pom.xmls from maven-build folder

bq. We have absolutely no idea what servlet container the user is going to use
for running the solr war.

It isnt important for this issue. Protecting the HTTP endpoints with
authentication and authorization is standardized in the servlet-spec. All
web-containers have to live up to that standard (to be certified). Only place
where the standardization is not very clear is how to install a realm (the
thingy knowing about user-credentials and roles), but all containers have
plenty of documentation on how to do it.

It is very important to understand that this issue, and the patch I provided
will work for any web-container. This issue is not about enforcing the
protection - let the web-container do that. This issue and the patch is ONLY
about enabling Solr to send credentials in its Solr-node-to-Solr-node requests,
so that things will keep working, if/when you make the obvious security
decision and make usage of the security-features provided to you for free by
the container.

bq. Solr has no control over the server-side HTTP layer right now, so anything
we try to do will almost certainly be wrong as soon as the user changes
containers or decides to modify their container config.

NO!

bq. Solr 5.0 will not ship as a .war file

Bad idea. This is one of the points where Solr did a better decision that ES

bq. Once Solr is a real application

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-09-16 Thread Sea Marie (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768980#comment-13768980
 ] 

Sea Marie edited comment on SOLR-4470 at 9/17/13 12:02 AM:
---

Hi,

I am running a simple two-node SolrCloud cluster with this patch (pulled from 
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty. 

I made a few small changes to the Jetty configs to restrict access via basic 
auth on all SOLR resources. After rebooting with these changes, the SolrCore on 
my second node is not coming up - it seems like the credentials are not being 
used in the core recovery code, or not being passed to ZooKeeper, or something. 
Have I missed some configuration step? Or am I confused and this scenario is 
not supported by this patch?

h5. Changes I made in Jetty to enable basic auth:

h6. etc/webdefault.xml (perhaps protecting everything is overly general?): 
  security-constraint
web-resource-collection
  web-resource-nameSolr authenticated application/web-resource-name
  url-pattern//url-pattern
/web-resource-collection
auth-constraint
  role-nameaccess-role/role-name
/auth-constraint
  /security-constraint

  login-config
auth-methodBASIC/auth-method
realm-nameAccess Realm/realm-name
  /login-config

h6. etc/jetty.xml:
Call name=addBean
  Arg
New class=org.eclipse.jetty.security.HashLoginService
  Set name=nameAccess Realm/Set
  Set name=configSystemProperty name=jetty.home 
default=.//etc/realm.properties/Set
  Set name=refreshInterval0/Set
/New
  /Arg
/Call

h6. etc/realm.properties (redacted for obvious reasons :))
  user: password, access-role

h5. Changes to SOLR-related things:
scripts/ctl.sh (on host2):

SOLR=$JAVABIN -Dbootstrap_confdir=$SOLR_HOME/collection1/conf 
-Dcollection.configName=myconf -DzkRun -DzkHost=host1:9983 
-Dsolr.solr.home=$SOLR_HOME -Djetty.logs=$INSTALL_PATH/logs/ 
-Djetty.home=$INSTALL_PATH/ -jar 
-DinternalAuthCredentialsBasicAuthUsername=user 
-DinternalAuthCredentialsBasicAuthPassword=password $INSTALL_PATH/start.jar 
$INSTALL_PATH/etc/jetty.xml

(on host1, same as above w/o the -DzkHost param)

h5. The error I'm seeing (on host2, the second node, only. host1, the 
leader is fine):
INFO  - 2013-09-16 23:36:58.409; 
org.apache.solr.client.solrj.impl.HttpClientUtil; Creating new http client, 
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
ERROR - 2013-09-16 23:36:58.433; org.apache.solr.common.SolrException; Error 
while trying to recover. 
core=collection1:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
 Server at http://host1:8983/solr returned non ok status:401, 
message:Unauthorized
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at 
org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:198)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:342)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:219)




  was (Author: sapphiremirage):
Hi,

I am running a simple two-node SolrCloud cluster with this patch (pulled from 
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty. 

I made a few small changes to the Jetty configs to restrict access via basic 
auth on all SOLR resources. After rebooting with these changes, the SolrCore on 
my second node is not coming up - it seems like the credentials are not being 
used in the core recovery code, or not being passed to ZooKeeper, or something. 
Have I missed some configuration step? Or am I confused and this scenario is 
not supported by this patch?

Here are the changes I made in Jetty to enable basic auth:

etc/webdefault.xml (perhaps protecting everything is overly general?): 
  security-constraint
web-resource-collection
  web-resource-nameSolr authenticated application/web-resource-name
  url-pattern//url-pattern
/web-resource-collection
auth-constraint
  role-nameaccess-role/role-name
/auth-constraint
  /security-constraint

  login-config
auth-methodBASIC/auth-method
realm-nameAccess Realm/realm-name
  /login-config

etc/jetty.xml:
Call name=addBean
  Arg
New class=org.eclipse.jetty.security.HashLoginService
  Set name=nameAccess Realm/Set
  Set name=configSystemProperty name=jetty.home 
default=.//etc/realm.properties/Set
  Set name=refreshInterval0/Set
/New
  /Arg
/Call

etc/realm.properties (redacted for obvious reasons :))
  user: password, access-role

And the changes to SOLR-related things:
scripts/ctl.sh (on host2):

SOLR=$JAVABIN -Dbootstrap_confdir=$SOLR_HOME/collection1/conf

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-09-16 Thread Sea Marie (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768980#comment-13768980
 ] 

Sea Marie edited comment on SOLR-4470 at 9/17/13 12:04 AM:
---

Hi,

I am running a simple two-node SolrCloud cluster with this patch (pulled from 
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty. 

I made a few small changes to the Jetty configs to restrict access via basic 
auth on all SOLR resources. After rebooting with these changes, the SolrCore on 
my second node is not coming up - it seems like the credentials are not being 
used in the core recovery code, or not being passed to ZooKeeper, or something. 
Have I missed some configuration step? Or am I confused and this scenario is 
not supported by this patch?

h5. Changes I made in Jetty to enable basic auth:

h6. etc/webdefault.xml (perhaps protecting everything is overly general?):
{noformat} 
  security-constraint
web-resource-collection
  web-resource-nameSolr authenticated application/web-resource-name
  url-pattern//url-pattern
/web-resource-collection
auth-constraint
  role-nameaccess-role/role-name
/auth-constraint
  /security-constraint

  login-config
auth-methodBASIC/auth-method
realm-nameAccess Realm/realm-name
  /login-config
{noformat}

h6. etc/jetty.xml:
{noformat}
Call name=addBean
  Arg
New class=org.eclipse.jetty.security.HashLoginService
  Set name=nameAccess Realm/Set
  Set name=configSystemProperty name=jetty.home 
default=.//etc/realm.properties/Set
  Set name=refreshInterval0/Set
/New
  /Arg
/Call
{noformat}
h6. etc/realm.properties (redacted for obvious reasons :))
{noformat}
  user: password, access-role
{noformat}

h5. Changes to SOLR-related things:
scripts/ctl.sh (on host2):
{noformat}
SOLR=$JAVABIN -Dbootstrap_confdir=$SOLR_HOME/collection1/conf 
-Dcollection.configName=myconf -DzkRun -DzkHost=host1:9983 
-Dsolr.solr.home=$SOLR_HOME -Djetty.logs=$INSTALL_PATH/logs/ 
-Djetty.home=$INSTALL_PATH/ -jar 
-DinternalAuthCredentialsBasicAuthUsername=user 
-DinternalAuthCredentialsBasicAuthPassword=password $INSTALL_PATH/start.jar 
$INSTALL_PATH/etc/jetty.xml
{noformat}
(on host1, same as above w/o the -DzkHost param)

h5. The error I'm seeing (on host2, the second node, only. host1, the 
leader is fine):
{noformat}
INFO  - 2013-09-16 23:36:58.409; 
org.apache.solr.client.solrj.impl.HttpClientUtil; Creating new http client, 
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
ERROR - 2013-09-16 23:36:58.433; org.apache.solr.common.SolrException; Error 
while trying to recover. 
core=collection1:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
 Server at http://host1:8983/solr returned non ok status:401, 
message:Unauthorized
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at 
org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:198)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:342)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:219)
{noformat}



  was (Author: sapphiremirage):
Hi,

I am running a simple two-node SolrCloud cluster with this patch (pulled from 
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty. 

I made a few small changes to the Jetty configs to restrict access via basic 
auth on all SOLR resources. After rebooting with these changes, the SolrCore on 
my second node is not coming up - it seems like the credentials are not being 
used in the core recovery code, or not being passed to ZooKeeper, or something. 
Have I missed some configuration step? Or am I confused and this scenario is 
not supported by this patch?

h5. Changes I made in Jetty to enable basic auth:

h6. etc/webdefault.xml (perhaps protecting everything is overly general?): 
  security-constraint
web-resource-collection
  web-resource-nameSolr authenticated application/web-resource-name
  url-pattern//url-pattern
/web-resource-collection
auth-constraint
  role-nameaccess-role/role-name
/auth-constraint
  /security-constraint

  login-config
auth-methodBASIC/auth-method
realm-nameAccess Realm/realm-name
  /login-config

h6. etc/jetty.xml:
Call name=addBean
  Arg
New class=org.eclipse.jetty.security.HashLoginService
  Set name=nameAccess Realm/Set
  Set name=configSystemProperty name=jetty.home 
default=.//etc/realm.properties/Set
  Set name=refreshInterval0/Set
/New
  /Arg
/Call

h6. etc/realm.properties (redacted for obvious reasons :))
  user: password, access-role

h5. Changes to

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-05-27 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667673#comment-13667673
]

Per Steffensen edited comment on SOLR-4470 at 5/27/13 10:05 AM:

bq. Could make an implementation which reads a system-basic-auth.properties
from ZK (given your ZK is encrypted). That would be useful once the other issue
about securing ZK is solved.

Guess you are talking about SOLR-4580. It is not about encryption (neither
storage- nor transport-level). It is about authentication and authorization at
application/API-level. But you are right, it is an option to build on top of
this issue and allow for those internal credentials to live in ZK - just make
sure the security issues doing that is dealt with.

bq. Q: Would it make sense to make CurrentInternalRequestFactory or
InterSolrNodeAuthCredentialsFactory pluggable through solr.xml? Currently you
need to patch and build Solr to change it, right?

Yes you need to patch and rebuild. But that is because it did not include as
much code in the patch as I wanted to, and as I did for SOLR-4580. In the patch
for SOLR-4580 I've included code so that you, through JVM params, can specify
the name of a class which will be used as credentials/ACL-provider. The same
should have been done in the patch for this SOLR-4470. I ought to have included
code so that you, through JVM params, can point out the classes you want to be
used as credentials-providers. Basically JVM params that is able to control
which implementations of InterSolrNodeAuthCredentialsFactory.SubRequestFactory
and InterSolrNodeAuthCredentialsFactory.InternalRequestFactory is to be used
default for InterSolrNodeAuthCredentialsFactory.CurrentSubRequestFactory and
InterSolrNodeAuthCredentialsFactory.CurrentInternalRequestFactory.

JVM params is the simplest way to control which implementations to be used
behind the interfaces. That is, in my opinion, what should have been included
here. Going from control through JVM params and adding support for control
through solr.xml or something else should be another issue, but it is certainly
a good and valid idea.

{quote}
bq. Solr is not enforcing security - the webcontainer or something else is.

A comment right in the patch explains this is not the case - it says the web
container authorizes any role and then new Solr code is responsible for dealing
with role authorization. This is Solr code that can introduce security bugs.
This is the slippery slope, this is the fuzzy line, this is the creep.
{quote}

Well you did not point out the exact comment as I asked you to, so I will have
to guess a little. The code going into the real non-test part of Solr does not
do anything to enforce security. It only enables a Solr admin to configure
Solr-nodes in a way so that their inter-communication will still work if the
Solr admin chooses to set up e.g. container-managed security.

I order to claim that my solution solves the problem I want to test that it
does. Test strategy: Set up container-managed security and verify that all
inter-Solr-node communitation works if you use my solution. So the test-code
sets up container-managed security, and in there there is a comment about just
letting the container manage authentication and handle authorization in a
filter. But this is all a simulation of what the Solr admin decided to do to
set up security. This is test only!

{quote}
bq. Personally I do not understand why a serious project would stay out of
security

It's simply the current stance of the project
{quote}

Well I havnt been on the meetings or whatever where this stance was
established, but I would imagine that this stance is about Solr not going down
the path of enforcing or controlling or ... security. I couldnt imagine that
this stance is about that we will not want a SolrClould cluster to work if an
Solr admin chooses to activate third party security in a very common way.

was (Author: steff1193):
bq. Could make an implementation which reads a system-basic-auth.properties
from ZK (given your ZK is encrypted). That would be useful once the other issue
about securing ZK is solved.

bq. Q: Would it make sense to make CurrentInternalRequestFactory or
InterSolrNodeAuthCredentialsFactory pluggable through solr.xml? Currently you
need to patch and build Solr to change it, right?

Yes you need to patch and rebuild. But that is because it did not include as
much code in the patch as I wanted to, and as I did for

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-05-27 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667712#comment-13667712
]

Jan Høydahl edited comment on SOLR-4470 at 5/27/13 12:02 PM:
-

bq. JVM params is the simplest way to control which implementations to be used
behind the interfaces. That is, in my opinion, what should have been included
here. Going from control through JVM params and adding support for control
through solr.xml or something else should be another issue, but it is certainly
a good and valid idea.

The way we normally set up {{solr.xml}} configs is with
mytag$\{my.jvm.param\}/mytag style, so admin can choose whether to pass the
option as JVM param or include it in solr.xml directly. Something like

{code:xml}
solr
...
subRequestFactory class=${solr.subRequestFactory} /
internalRequestFactory class=${solr.internalRequestFactory} /
/solr
{code}

Regarding [~markrmil...@gmail.com]'s concern with authorization creep, I to
some extent agree. But since, as you say, this is test-code only, let's move
the class {{RegExpAuthorizationFilter}} from runtime codebase and into the test
framework. In that way, it is clear that it is only used for realistic test
coverage. And if anyone wishes to setup a similar setup in their production
they may borrow code from the test class, but it will be a manual step
reinforcing that this is not a supported feature of the project as such.

was (Author: janhoy):
bq. JVM params is the simplest way to control which implementations to be
used behind the interfaces. That is, in my opinion, what should have been
included here. Going from control through JVM params and adding support for
control through solr.xml or something else should be another issue, but it is
certainly a good and valid idea.

{code:xml}
solr
...
subRequestFactory class=${solr.subRequestFactory} /
internalRequestFactory class=${solr.internalRequestFactory} /
/solr
{code}

Support for basic http auth in internal solr requests
-

Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.patch

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-05-27 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667754#comment-13667754
]

Jan Høydahl edited comment on SOLR-4470 at 5/27/13 1:59 PM:

I tried to move {{RegExpAuthorizationFilter}} to test scope, but there is a
compile-time dependency in JettySolrRunner method lifeCycleStarted(). Can we
refactor this piece of code into test-scope as well, e.g. by exposing some a
Filter setter on JettySolrRunner?

was (Author: janhoy):
I tried to move AuthCredentialsSource to test scope, but there is a
compile-time dependency in JettySolrRunner method lifeCycleStarted(). Can we
refactor this piece of code into test-scope as well, e.g. by exposing some a
Filter setter on JettySolrRunner?

Support for basic http auth in internal solr requests
-

Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.patch

--
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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-05-23 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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!

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

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
-

Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.patch

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-05-23 Thread Alexey Serba (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665187#comment-13665187
]

Alexey Serba edited comment on SOLR-4470 at 5/23/13 2:03 PM:
-

bq. The reasoning is that, in general you do not want a user to be able to have
something done (by the subrequest) for him, that we was not allowed to do
directly himself - forwarding credentials will ensure that.

[~steff1193], but -this patch currently only does authn and not authz part- I
haven't seen examples how Solr users should implement per-collection or
per-document security. That's why I don't understand how someone would use
forwarding credentials feature if Solr does not provide any way (best
practices, recipes, whatever) to enforce authz policies / security.

How do you do that in your application? How do you specify who can do what?
Where do you enforce that - in custom UpdateProcessor, SearchComponent,
SolrDispathFilter?

was (Author: alexey):
bq. The reasoning is that, in general you do not want a user to be able to
have something done (by the subrequest) for him, that we was not allowed to do
directly himself - forwarding credentials will ensure that.

[~steff1193], but this patch currently only does authn and not authz part.
That's why I don't understand how someone would use forwarding credentials
feature if Solr does not provide any way (best practices, recipes, whatever) to
enforce authz policies / security.

How do you do that in your application? How do you specify who can do what?
Where do you enforce that - in custom UpdateProcessor, SearchComponent,
SolrDispathFilter?

Support for basic http auth in internal solr requests
-

Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-30 Thread Tim Vaillancourt (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618173#comment-13618173
]

Tim Vaillancourt edited comment on SOLR-4470 at 3/30/13 10:17 PM:
--

I'm running the SOLR-4470_branch_4x_r145.patch now, and can say it's
working as expected - all my smoke tests are passing and Collections API
CREATE/DELETEs are applying Authorization headers flawlessly. Thanks for your
work on this patch!!

I'm very excited for this patch to make it to mainline. I will say that
passwords in JVM command-lines frighten me, but it is far better than none :),
and I think this is the best approach for now.

was (Author: tvaillancourt):
I'm running the SOLR-4470_branch_4x_r145.patch now, and can say it's
working as expected - all my smoke tests are passing and Collections API
CREATE/DELETEs are applying Authorization headers flawlessly. Thanks for your
work on this patch!!

I'm very excited for this patch to make it to mainline. :)

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.3

Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-30 Thread Tim Vaillancourt (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618173#comment-13618173
]

Tim Vaillancourt edited comment on SOLR-4470 at 3/30/13 10:18 PM:
--

I'm very excited for this patch to make it to mainline. 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.

I'm very excited for this patch to make it to mainline. I will say that
passwords in JVM command-lines frighten me, but it is far better than none :),
and I think this is the best approach for now.

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.3

Attachments: SOLR-4470_branch_4x_r1452629.patch,
SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch,
SOLR-4470.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-30 Thread Tim Vaillancourt (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618197#comment-13618197
 ] 

Tim Vaillancourt edited comment on SOLR-4470 at 3/31/13 1:09 AM:
-

So after some more testing, I've noticed that the Authorization headers get 
applied to inter-node requests ONLY when these JVM flags are added:

-DinternalAuthCredentialsBasicAuthUsername=username 
-DinternalAuthCredentialsBasicAuthPassword=password

Without those two JVM flags the Authorization headers ARE NOT passed along on 
inter-node calls. I noticed in one of Per's original posts he mentioned a 
two-sided behavior where the headers are provided from the JVM properties (the 
method that works for me), but also a behavior where they would be passed down 
from the original Collections API call, an approach I personally like much 
more. Is the later approach I mentioned working, or just not in this patch? It 
currently does not work for me.

To reduce changes, simplify the problem and keep more in the container-level, 
could we introduce a Limitation/Caveat that all SolrCloud nodes MUST HAVE the 
same basic-auth password, and rely solely on the Collections API request to 
provide the Authorization header (to be used on subrequests), vs having the 
user/password in the JVM properties/app level at all?

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. To me Solr solely relying on the external call to provide the 
credentials it is more secure, simpler and keeps Solr less involved in security 
above it.

  was (Author: tvaillancourt):
So after some more testing, I've noticed that the Authorization headers get 
applied to inter-node requests ONLY when these JVM flags are added:

-DinternalAuthCredentialsBasicAuthUsername=username 
-DinternalAuthCredentialsBasicAuthPassword=password

Without those two JVM flags the Authorization headers ARE NOT passed along on 
inter-node calls. I noticed in one of Per's original posts he mentioned a 
two-sided behavior where the headers are provided from the JVM properties (the 
method that works for me), but also a behavior where they would be passed down 
from the original Collections API call, an approach I personally like much 
more. Is the later approach I mentioned working, or just not in this patch?

To reduce changes, simplify the problem and keep more in the container-level, 
could we introduce a Limitation/Caveat that all SolrCloud nodes have the same 
password on all nodes, and rely solely on the Collections API request to 
provide the Authorization header (to be used on subrequests), vs having the 
user/password in the JVM properties/app level at all?

Keep in mind that the Solr Web interface and ps commands on systems will 
display the entire JVM command line, in this case with password plain text if 
in JVM command. To me Solr relying on the external call to provide it is more 
secure, simpler and keeps Solr less involved in security.
  
 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.3

 Attachments: SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-30 Thread Tim Vaillancourt (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13618197#comment-13618197
 ] 

Tim Vaillancourt edited comment on SOLR-4470 at 3/31/13 1:12 AM:
-

So after some more testing, I've noticed that the Authorization headers get 
applied to inter-node requests ONLY when these JVM flags are added:

-DinternalAuthCredentialsBasicAuthUsername=username 
-DinternalAuthCredentialsBasicAuthPassword=password

Without those two JVM flags the Authorization headers ARE NOT passed along on 
inter-node calls. I noticed in one of Per's original posts he mentioned a 
two-sided behavior where the headers are provided from the JVM properties (the 
method that works for me), but also a behavior where they would be passed down 
from the original Collections API call, an approach I personally like much 
more. Is the later approach I mentioned working, or just not in this patch? It 
currently does not work for me.

To reduce changes, simplify the problem and keep more in the container-level, 
could we introduce a Limitation/Caveat that all SolrCloud nodes MUST HAVE the 
same basic-auth password, and rely solely on the Collections API request to 
provide the Authorization header (to be used on subrequests), vs having the 
user/password in the JVM properties/app level at all?

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. To me Solr solely relying on the external call to provide the 
credentials it is more secure, simpler and keeps Solr less involved in security 
above it.

Long story short: could the ONLY approach be take the Authorization header from 
the external request, applying it to subsequent inter-node ones, making this a 
simpler and possibly more secure change?

  was (Author: tvaillancourt):
So after some more testing, I've noticed that the Authorization headers get 
applied to inter-node requests ONLY when these JVM flags are added:

-DinternalAuthCredentialsBasicAuthUsername=username 
-DinternalAuthCredentialsBasicAuthPassword=password

Without those two JVM flags the Authorization headers ARE NOT passed along on 
inter-node calls. I noticed in one of Per's original posts he mentioned a 
two-sided behavior where the headers are provided from the JVM properties (the 
method that works for me), but also a behavior where they would be passed down 
from the original Collections API call, an approach I personally like much 
more. Is the later approach I mentioned working, or just not in this patch? It 
currently does not work for me.

To reduce changes, simplify the problem and keep more in the container-level, 
could we introduce a Limitation/Caveat that all SolrCloud nodes MUST HAVE the 
same basic-auth password, and rely solely on the Collections API request to 
provide the Authorization header (to be used on subrequests), vs having the 
user/password in the JVM properties/app level at all?

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. To me Solr solely relying on the external call to provide the 
credentials it is more secure, simpler and keeps Solr less involved in security 
above it.
  
 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.3

 Attachments: SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-06 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13594492#comment-13594492
]

Per Steffensen edited comment on SOLR-4470 at 3/6/13 8:38 AM:
--

bq. You could run it anyway.

I will bring a patch passing precommit shortly

bq. Perhaps you can catch another committers attention.

Hopefully

bq. It would in my eyes be wiser to split the elephant

I agree, but it is hard, because the changes in the actual non-test code is not
that comprehensive. I will try though, if a least one committer indicates that
he will take the patch seriously and spent some time on this issue.

bq. Is there some major part you can leave out and start with the simplest
possible codebase to enable simple auth on internal requests only?

Actually that is all it is already - besides I fixed the PeerSync.close issue,
which is just a few lines. Most of the patch is related to testing, and I dont
like to deliver parts that are not thoroughly tested.

bq. Another option is to do the finalization of auth in a new branch

We could do that, but will it make a difference? The end goal is to have it on
a branch from which an actual release will be build. The changes will become
hard to merge very soon anyway - wont they?

bq. Just a pity non-committers can't work with branches in svn

Well, I guess it wouldnt be that hard if the branch is made from branch_4x
revision 1452629 - the patch will fit without any problems.

bq. I could create a branch off trunk for you and commit your code to it if
you're willing to make it apply

I dont know the magnitude of the diff between branch_4x and trunk - according
to Mark they where almost equal some time ago, but that might not be the case
anymore? Besides that you indicated earlier that it wouldnt matter if it was a
bracn_4x or a trunk patch. But I think I would be able to create a patch
fitting trunk fairly easy. But again, there is no need I do this, if no
committer is willing to actually take this patch seriously and work a little
bit with it. But if you think it makes a difference Jan, I will do it? But
please also consider just making the branch from branch_4x and it will fit
without problems.

bq. Oh, I don't mind if he runs precommit or not - I don't think contributors
need to.

That was my impression too

bq. I've just read enough little negative jabs through all of the issues I've
interacted with Per on that I'm ready to let someone else work with him if they
desire. Getting into security like this has usually been avoided with Solr -
coming in with a bad attitude just seems counter productive.

Maybe it is just because I actually give a damn. Unfortunately I have to say
that I do not believe Solr(Cloud) will become a serious competition to
ElasticSearch (and others), if quality of code and committer attitude do not
change. The code is a mess and will not be maintainable for very long if
way-of-working do not change. The main reason is that apparently no one ever
refactor. It is all just small patches on top of already messy code making it
even more messy. It is like you are not allowed to do natural refactoring
because it make a patch bigger than the absolute minimum to introduce the new
feature. And apparently we do not trust the test-suite enough to say, that if
it is green after a patch (and you didnt actually delete, modify or ignore
existing tests in a suspicious manner), nothing was broken. It is an illusion
that people will ever do refactor/cleanup-only patches - refactoring/cleanup is
something you do as a natural thing when touching the code for other reasons.
And even if someone actually did a refactor/cleanup-only patch it would
probably be too big by itself to make it into the code anyway.

The small jabs are continuous attempt to try to influence things that I believe
is bad around Solr, and it IS because I give a damn, so IMHO the bad attitude
is not on my side, it is on (some of) the Solr-core-members side. Doing
retrospective sessions among Solr-core-members might be a good idea, to at
least consider what works well and what might needs some twisting (process- and
code-requirements-wise). And I am a little surprised that this single last line
it my thorough description above was the only one that really got some
attention. It is a one-line small jab in a big productive description.

Of course I accept current rules and agreed-ways-to-do-things, but it will not
stop me trying to change it wherever I think it is currently wrong. Because I
give a damn.

Maybe Solr-core-members also have something to learn from developers outside
the Solr-core. I have a lot of experience as a developer, architect, mentor,
teacher etc., and I have strong opinions based on experience. But I am aways
ready to listen to arguments and learn, and you have heard me (several time)
say I stand corrected when I

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-06 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13594627#comment-13594627
 ] 

Per Steffensen edited comment on SOLR-4470 at 3/6/13 11:39 AM:
---

New patch. Passes precommit if you do the following
{code}
cd checkout-of-branch_4x-r1452629
patch -p0 -i SOLR-4470_branch_4x_r1452629.patch
svn stat | grep ^? | awk '{print $2}' | xargs svn add
svn propset svn:eol-style native 
solr/core/src/java/org/apache/solr/security/InterSolrNodeAuthCredentialsFactory.java
svn propset svn:eol-style native 
solr/core/src/java/org/apache/solr/servlet/security/RegExpAuthorizationFilter.java
svn propset svn:eol-style native 
solr/core/src/test/org/apache/solr/cloud/SecurityDistributedTest.java
svn propset svn:eol-style native 
solr/solrj/src/java/org/apache/solr/security/AuthCredentials.java
svn propset svn:eol-style native 
solr/test-framework/src/java/org/apache/solr/cloud/InterSolrNodeAuthCredentialsFactoryTestingHelper.java
ant precommit
{code}

Only problem is that it says Linting documentation HTML is not supported on 
this Java version (1.6) / JVM (Java HotSpot(TM) 64-Bit Server VM)., but I 
guess that is because I am not is.jenkins.build, and I do not know what to do 
about that on my local machine. If I comment out the stuff in target 
-documentation-lint-unsupported in lucene/common-build.xml it passes ant 
precommit

Besides that, the new patch contains a small modification to 
RegExpAuthorizationFilter so that it works in both a real jetty and in a 
test jetty (started by JettySolrRunning). Strange but 
HttpServletRequest.getPathInfo() returns the correct path in test jetty, but 
returns null in real jetty. And HttpServletRequest.getServletPath() returns 
correct path in real jetty, but returns empty/null in test jetty - so now 
we use whatever is non-null/empty.


  was (Author: steff1193):
New patch. Passes precommit if you do the following
{code}
cd checkout-of-branch_4x-r1452629
patch -p0 -i SOLR-4470_branch_4x_r1452629.patch
svn stat | grep ^? | awk '{print $2}' | xargs svn add
svn propset svn:eol-style native 
solr/core/src/java/org/apache/solr/security/InterSolrNodeAuthCredentialsFactory.java
svn propset svn:eol-style native 
solr/core/src/java/org/apache/solr/servlet/security/RegExpAuthorizationFilter.java
svn propset svn:eol-style native 
solr/core/src/test/org/apache/solr/cloud/SecurityDistributedTest.java
svn propset svn:eol-style native 
solr/solrj/src/java/org/apache/solr/security/AuthCredentials.java
svn propset svn:eol-style native 
solr/test-framework/src/java/org/apache/solr/cloud/InterSolrNodeAuthCredentialsFactoryTestingHelper.java
ant precommit
{code}

Only problem is that it says Linting documentation HTML is not supported on 
this Java version (1.6) / JVM (Java HotSpot(TM) 64-Bit Server VM)., but I 
guess that is because I am not is.jenkins.build, and I do not know what to do 
about that on my local machine. If I comment out the stuff in target 
-documentation-lint-unsupported in lucene/common-build.xml it passes ant 
precommit

  
 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

 Attachments: SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-03-06 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13593830#comment-13593830
 ] 

Per Steffensen edited comment on SOLR-4470 at 3/6/13 12:09 PM:
---

About SOLR-4470_branch_4x_r1452629.patch
* Fits on top of branch_4x revision 1452629
* Fairly big patch but most of it is to provide credentials across all requests 
issued by BaseDistributedSearchTest tests or to just to forward decisions on 
credentials down the call-flow on server-side. Notes on the major changes in 
non-test code
** AuthCredentials: New class encapsulating the concept of credentials. 
Supports http basic only for now, but using this object across code wherever 
credentials are needed, the framework will be in place for supporting other 
kinds of credentials in the future
** InterSolrNodeAuthCredentialsFactory: Separation of concern with respect to 
getting credentials for inter-solr-node requests. The implementation of the 
factory can be replaced to change strategy, but this is only used in tests 
(for now)
** InterSolrNodeAuthCredentialsFactory.AuthCredentialsSource: A level of 
abstraction to be used server-side whenever you have to decide on how to get 
credentials for sub-requests - possible decisions are use credentials from 
super-request or use internal credentials but NOT use no credentials. Any 
server-side code should be able to provide credentials in requests, because you 
never know if the solr-cluster has been set up with protection on the URL you 
are about to hit. Therefore there are basically only the two choices listed 
above. The credentials (internal or on super-request) might be empty/null in 
concrete cases if no internal credentials has been specified or of no 
credentials was provided in the super-request, but you as a programmer never 
know, so you have to decide on how to get credentials for sub-requests for 
your server-side case. Idea is to use credentials from super-request whenever 
such exists, so that a request from the outside can never trigger a 
sub-request that the outside user was not allowed to do directly by himself. 
Whenever there is no super-request use internal credentials. There are 
gray-area-cases like e.g. the Observer that asynchronously issues requests to 
CoreAdmin API when the Collection API has been called from the outside - to 
be true to the idea, in this case, we ought to actually use the credentials 
provided in the original request to Collection API, but that would require 
writing those credentials into the ZK-queue, and I wouldn't include that now, 
so in this case we use internal credentials. Server-side methods should 
typically not take AuthCredentials-parameters, because that will not 
encourage/remind developers to decide on the strategy when they use the method 
in the future - use AuthCredentialsSource instead.
** SolrRequest: Has been modified so that it can hold credentials to be used, 
and info on whether or not to provide them preemptively
** SolrQueryRequest: Has been modified to hold the credentials used in the 
request received
** SolrRequestParsers: Has been modified to extract the credentials from the 
request and add it to SolrQueryRequest
** HttpClientUtil: Has been changed to allow for specifying credentials and/or 
ClientConnectionManager when creating a HttpClient. Credentials to be used 
across all requests issued by this HttpClient. ClientConnectionManager to be 
able to share connection-manager across HttpClients - see reason below
** HttpShardHandler(Factory): It is used many places (and thats good) where 
sub-request are issued, places doing use internal credentials but also places 
use credentials from super-request (SolrCmdDistributor) and therefore 
HttpShardHandler(Factory) has been modified to support both.
** LBHttpSolrServer: Changed to allow for specific HttpClient for each request, 
so that even the loadbalancer in HttpShardHandler can use different HttpClients 
for different requests. It should have been done this way from the beginning - 
it is strange to use the defaultHttpClient for loadbalancing request through a 
HttpShardHandler which has been created with a specific HttpClient to use.
** Shared ClientConnectionManager instead of HttpClient: Several classes that 
used to have a HttpClient used for all requests (PeerSync, SyncStrategy and 
UpdateShardHandler), now have only a shared ClientConnetionManager. This in 
order to be able to specify different credentials (on HttpClient level) for 
different requests issued through those components. Actually it is not absolute 
necessary for PeerSync because it always uses internal credentials, but it is 
done anyway in order to allow HttpShardHandlerFactory to insist on getting a 
decision on how to get credentials for sub-requests even when you bring you 
own client - shardhandlers ALWAYS need to have a strategy for providing 
credentials, because

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-23 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-21 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583030#comment-13583030
]

Per Steffensen edited comment on SOLR-4470 at 2/21/13 9:17 AM:
---

bq. then put a programmable proxy in front of Solr, like Varnish or something

Uhhh, I think that is too much to require for doing faily simple authorization.
And depending on where you put Varnish the authorization might not be preformed
on solr-to-solr requests, and one of the focus points here is to make sure it
is, because we basically do not want to make it possible to have a solr-to-solr
request R2 performed as a direct reaction to a request R1 comming from the
outside, where the outside user is authorized to do R1 but not to do R2.

But I guess it can fairly easy be done using a filter, and I will put up a
description on Wiki on how to do it. We are going to do it anyway in my project.

was (Author: steff1193):
bq. then put a programmable proxy in front of Solr, like Varnish or
something

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

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-20 Thread Per Steffensen (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582144#comment-13582144
 ] 

Per Steffensen edited comment on SOLR-4470 at 2/20/13 1:29 PM:
---

I think you should be able to specify credentials both on SolrServer-level (all 
requests made through this will have the same credentials added) and on 
SolrRequest-level (so that you can use the same SolrServer for sending requests 
with different credentials). I added a credentials-field on SolrRequest and it 
is all fine if you create the SolrRequest object yourself, but unfortunately 
there are a set of helper-methods on SolrServer that basically create the 
SolrRequest object for you without giving you a change to modify it afterwards. 
How do we prefer to hand over credentials for those SolrRequests? Ideas on 
the top of my head:
* 1) Add a credentials-param to all the helper-methods (maybe make two 
versions of each method - one that do and one that does not take a credentials 
object)
* 2) Change SolrRequest constructor so that it supports reading credentials 
from a threadlocal, that you will need to set before calling one of the 
helper-methods (instead of providing it as a parameter to the helper-method)

I wouldnt want to do 1) before agreed by the community, and 2) is kinda hacky 
(even though I like to use threadlocals a lot more than what the average 
developer seem to do). It seems like 1) was used back when commitWithinMs was 
added, but maybe it is not the way to continue - we will end up with huge set 
of similar (except for parameter differences) helper-methods. Actually I 
would have preferred that commitWithinMs was never made this way - maybe one 
should have foreseen that this is not the last parameter you want to be able to 
give to the helper-methods in general, so maybe back then you should have 
introduced a callback-thingy instead of the commitWithinMs-parameter - a 
callback-thingy that could be used for modifying the SolrRequest object after 
it had been set up by the helper-method.
* 3) Of course that is also an option now, but then we should really get rid of 
commitWithinMs and that will break API backwards compatibility.

  was (Author: steff1193):
I think you should be able to specify credentials both on SolrServer-level 
(all requests made through this will have the same credentials added) and on 
SolrRequest-level (so that you can use the same SolrServer for sending requests 
with different credentials). I added a credentials-field on SolrRequest and it 
is all fine if you create the SolrRequest object yourself, but unfortunately 
there are a set of helper-methods on SolrServer that basically create the 
SolrRequest object for you without giving you a change to modify it afterwards. 
How do we prefer to hand over credentials for those SolrRequests? Ideas on 
the top of my head:
* 1) Add a credentials-param to all the helper-methods (maybe make two 
versions of each method - one that do and one that does not take a credentials 
object)
* 2) Change SolrRequest constructor so that it supports reading credentials 
from a threadlocal, that you will need to set before calling one of the 
helper-methods (instead of providing it as a parameter to the helper-method)

I wouldnt want to do 1) before agreed by the community, and 2) is kinda hacky 
(even though I like to use threadlocals a lot more than what the average 
developer seem to do). It seems like 1) was used back when commitWithinMs was 
added, but maybe it is not the way to continue - we will end up with huge set 
of similar (except for parameter differences) helper-methods. Actually I 
would have preferred that commitWithinMs was never made this way - maybe one 
should have foreseen that this is not the last parameter you want to be able to 
give to the helper-methods in general
3) Maybe back then you should have introduced a callback-thingy instead of the 
commitWithinMs-parameter that could be used for modifying the SolrRequest 
object after it had been set up by the helper-method
Of course 3) would also be an option now, but then we should really get rid of 
commitWithinMs and that will break API backwards compatibility.
  
 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

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-20 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582274#comment-13582274
]

Per Steffensen edited comment on SOLR-4470 at 2/20/13 4:13 PM:
---

Usually you structure URLs in you web-app by increasing level of detail from
left to right. This way you can configure the web-container to handle the most
obvious security-constraints.

Unfortunately, IMHO, Solr URLs are not structured by increasing level of
detail - e.g. /solr/collection1/update should have been
/solr/update/collection1 (I consider collection/replica as a higher level
of detail than update). Due to limitations on url-patterns in
security-constraint|web-resource-collection's in web.xml (or webdefault.xml
for jetty) you cannot write e.g. url-pattern/solr/\*/update/url-pattern,
url-pattern\*/update/url-pattern or url-pattern\*update/url-pattern to
protect updates - it is not allowed - you can only have * in the end or as part
of an extension-pattern (*.ext - and the . needs to be there).

Therefore it is not possible (AFAIK) to configure the web-container to protect
update-operation or select-operation etc. You can configure protection on
all operations for a specific collection (but not specific operations
cross-collections), but it is much more unlikely that that is what you want to
do. Or by mentioning url-pattern/solr/collection-name/update/url-pattern
for every single collection in your setup you can actually protect e.g. update,
but that is not possible for those of us that have a dynamic/ever-changing set
of collections.

Possible solutions from the top of my head
* 1) Make Solr URL structure right - e.g. /solr/update/collection1
* 2) Make obvious security constraints like protecting update or protecting
search etc. impossible to be done by web.xml configuration, and leave it up to
programmatic protection
I like 1) best, but is that at all feasible, or will it just be way to much
work?
Since Solr is usually not something you change yourself, but something you use
out-of-the-box, potentially modifying deployment-descriptors (e.g. web.xml),
config files etc. 2) will really not help the normal Solr user and it will
also be a problem figuring out exactly where to place this programmatic
protection-code, because despite most Solr-stuff is handled by
SolrDispatchFilter there are several resources that is not handled through it.

was (Author: steff1193):
Usually you structure URLs in you web-app by increasing level of detail
from left to right. This way you can configure the web-container to handle the
most obvious security-constraints.

Unfortunately, IMHO, Solr URLs are not structured by increasing level of
detail - e.g. /solr/collection1/update should have been
/solr/update/collection1 (I consider collection/replica as a higher level
of detail than update). Due to limitations on url-patterns in
security-constraint|web-resource-collection's in web.xml (or webdefault.xml
for jetty) you cannot write e.g. url-pattern/solr/*/update/url-pattern,
url-pattern*/update/url-pattern or url-pattern*update/url-pattern to
protect updates - it is not allowed - you can only have * in the end or as part
of an extension-pattern (*.ext - and the . needs to be there).

Support for basic http auth in internal solr requests
-

Key: SOLR-4470
URL:

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-20 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582274#comment-13582274
]

Per Steffensen edited comment on SOLR-4470 at 2/20/13 4:16 PM:
---

Usually you structure URLs in you web-app by increasing level of detail from
left to right. This way you can configure the web-container to handle the most
obvious security-constraints.

I like 1) best, but is that at all feasible, or will it just be way to much
work?
Since Solr is usually not something you change yourself, but something you use
out-of-the-box, potentially modifying deployment-descriptors (e.g. web.xml),
config files etc. 2) will really not help the normal Solr user and it will
also be a problem figuring out exactly where to place this programmatic
protection-code, because despite most Solr-stuff is handled by
SolrDispatchFilter there are several resources that is not handled through it.

Support for basic http auth in internal solr requests
-

Key: SOLR-4470
URL:

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-19 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580705#comment-13580705
]

Per Steffensen edited comment on SOLR-4470 at 2/19/13 8:06 AM:
---

bq. Acording to HTTP-URL syntax, you can give the basic auth params using
http://user:password@host:port/. As Solr is using Commons-Httpsclient for
connections, wouldnt this work automatically if you configure the node's HTTP
adress using this syntax?

This is a way to specify the credentials, yes. But it can be done in other ways
and is already done in other ways in the code - see HttpClientUtil.setBasicAuth
(have to say that I am currently looking at 4.0 code, but guess it hasnt
changed). The problem is not so much setting the credentials for the internal
request, but to figure out which credentials to use.
As I described above I would like the credentials for requests issued by
Solr-nodes themselves, to be copied from the originals super-request in cases
where such exist - e.g. for search and update. For some of the requests that
Solr-nodes issue themselves there are no such super-request (e.g. for sync
stuff) and for other requests the sub-requests are issued asynchronously from
its super-request (e.g. replica-creation-request are issued asynchronously from
a create request to the Collection API). For both such kind of request we need
some credentials to include. Thats where configuring internal credentials is
needed.

If you where thinking about actually writing URLs like
http://user:password@host:port/; in ZK, that is not going to work, since
username/password is not (necessarily) static per target-node. I want to
forward whatever credentials are given in the super-request to the
sub-requests triggered synchronously by this super-requests (e.g. search and
update) whereas internal credentials will be used when there is no such
super-request (sync stuff) or when there is an asynchronous border between the
super-request and the sub-requests (e.g. Collection API operations). Besides
that we plan to (later) go for HTTPS in order to encrypt the clear text (or
base64 encoded, but that can easily be decoded) username/password in the
requests, and I believe that the URL itself is not being encrypted in HTTPS.

Very concrete in our usage of Solr, we (for now) would like to have two users
* Admin-user which is allowed to do everything
* Search-user which is only allowed to search

We will configure solr-nodes with the Admin-user credentials as internal
credentials. So they will be used for replica-creation and sync stuff. But
outside users of our application we only be given the Search-user
credentials, and we want to make sure that they are not allowed to do anything
but search. It is not cool if a request made with the Search-user credentials
results in sub-requests with Admin-user credentials.

Hope it makes a little bit of sense, of else I hope it will when I provide some
code. I will post patch soon with early version of my work.

was (Author: steff1193):
bq. Acording to HTTP-URL syntax, you can give the basic auth params using
http://user:password@host:port/. As Solr is using Commons-Httpsclient for
connections, wouldnt this work automatically if you configure the node's HTTP
adress using this syntax?

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-18 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580512#comment-13580512
]

Per Steffensen edited comment on SOLR-4470 at 2/18/13 11:19 AM:

First idea was to put internal credentials in solrconfig.xml, but
solrconfig.xml is part of a configuration of one or more
replica/shards/collections, and the internal credentials really should not be
per shard but per node or per cluster. Guess per node be implemented as
either put in solr.xml or give as VM-params, but I dont know if there are
future plans on getting rid of solr.xml. Per cluster could be implemented by
put in ZK (at a global location). This will of course raise another issue of
protecting access to solr.xml or ZK. We have an upcoming US focusing on
protecting stuff in ZK, so we plan to deal with that part. Files can be
protected in misc ways based on the OS.

Opinions from the community please:
* solr.xml?
* global location in ZK?
* or, do you think this is a solrconfig.xml thingy?

was (Author: steff1193):
We suggest putting internal credentials in solrconfig.xml, which is
either stored as files or in ZK. This will of course raise another issue of
protecting access to files/ZK. We have an upcomming US focusing on protecting
stuff in ZK, so we plan to deal with that part. Files can be protected in misc
ways based on the OS.

Support for basic http auth in internal solr requests
-

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-18 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580512#comment-13580512
]

Per Steffensen edited comment on SOLR-4470 at 2/18/13 11:21 AM:

First idea was to put internal credentials in solrconfig.xml, but
solrconfig.xml is part of a configuration of one or more
replica/shards/collections, and the internal credentials really should not be
per shard but per node or per cluster. Guess per node could be
implemented as either put in solr.xml or give as VM-params, but I dont know
if there are future plans on getting rid of solr.xml. Per cluster could be
implemented by put in ZK (at a global location). This will of course raise
another issue of protecting access to solr.xml or ZK, but that is already
relevant as it is today. We have an upcoming US focusing on protecting stuff in
ZK, so we plan to deal with that part. Files can be protected in misc ways
based on the OS.

Opinions from the community please:
* solr.xml?
* global location in ZK?
* or, do you think this is a solrconfig.xml thingy?

was (Author: steff1193):
First idea was to put internal credentials in solrconfig.xml, but
solrconfig.xml is part of a configuration of one or more
replica/shards/collections, and the internal credentials really should not be
per shard but per node or per cluster. Guess per node be implemented as
either put in solr.xml or give as VM-params, but I dont know if there are
future plans on getting rid of solr.xml. Per cluster could be implemented by
put in ZK (at a global location). This will of course raise another issue of
protecting access to solr.xml or ZK. We have an upcoming US focusing on
protecting stuff in ZK, so we plan to deal with that part. Files can be
protected in misc ways based on the OS.

Opinions from the community please:
* solr.xml?
* global location in ZK?
* or, do you think this is a solrconfig.xml thingy?

Support for basic http auth in internal solr requests
-

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

2013-02-18 Thread Per Steffensen (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580705#comment-13580705
]

Per Steffensen edited comment on SOLR-4470 at 2/18/13 4:44 PM:
---

Very concrete in our usage of Solr, we (for now) would like to have two users
* Admin-user which is allowed to do everything
* Search-user which is only allowed to search

Hope it makes a little bit of sense, of else I hope it will when I provide some
code. I will post patch soon with early version of my work.

Very concrete in our usage of Solr, we (for now) would like to have two users
* Admin-user which is allowed to do everything
* Search-user which is only allowed to search
We will configure solr-nodes with the Admin-user credentials as internal
credentials. So they will be used

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

33 matches

Site Navigation

Mail list logo

Footer information