[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 believe I learned something. I expected others
do be ready to listen and learn too. Arguments count - not "counter productive"
attitudes like "we have always done it this way and it is the right thing to
do" and "people trying to change things are just counter productive".
bq. You'll want Mark & Yonik on your side here
Yes certainly, but I probably didnt make progress in that area by the
statements above
was (Author: steff1193):
.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 believe I learned something. I expected others
do be ready to listen and learn too. Arguments count - not "counter productive"
attitudes like "we have always done it this way and it is the right thing to
do" and "people trying to change things are just counter productive".
.bq You'll want Mark & Yonik on your side here
Yes certainly, but I probably didnt make progress in that area by the
statements above
> 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
>
>
> 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
