[ 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