Auth tie in to core, solrJ, AdminUI and bin/solr. Currently we can only make packages for core. Should look in to extend the package spec to support plugging in these other parts too.
But guess we could make Core parts of the auth plug-ins into (1st party) packages and just leave the html and, bin/solr parts where they are. I vote for one package per auth type. Perhaps basic auth can remain in core, it does not have any jar reps? Jan Høydahl > 5. mar. 2021 kl. 18:59 skrev Tomás Fernández Löbbe <tomasflo...@gmail.com>: > > > +1 David > > Oh I see; there are entanglements with Solr's authentication plugins > Maybe we should move the authentication plugins to contribs (don't know if > we'll need one or two, one for client-side and one for server-side? I haven't > looked much at the code). Plus, we are shipping with multiple authentication > options, while at most one will be used. > > > An even smaller baby step is to mark the httpclient dependency as > > "optional" in the Maven pom we generate. This is a clue to consumers to > > move on > > Also marking HttpSolrClient deprecated > +1 > >> On Fri, Mar 5, 2021 at 8:18 AM David Smiley <david.w.smi...@gmail.com> wrote: >> An even smaller baby step is to mark the httpclient dependency as "optional" >> in the Maven pom we generate. This is a clue to consumers to move on. >> Also marking HttpSolrClient deprecated. >> >> ~ David >> >>> On Fri, Mar 5, 2021 at 11:06 AM David Smiley <david.w.smi...@gmail.com> >>> wrote: >>> Oh I see; there are entanglements with Solr's authentication plugins :-( >>> One step in this direction is to *move* it from SolrJ to solr-core. If >>> someone using SolrJ wants to pass whatever security tokens in headers, they >>> can add their own interceptors. Also, SolrJ 8 will likely work fine with >>> SolrJ 9, so if there are unforeseen problems after 9.0, we can address them >>> in 9.1 and users that are affected by whatever the problem is can still use >>> SolrJ 8 as an option. >>> >>> Maintaining two HTTP client code paths is a pain. It makes for possibly >>> duplicative work in metrics, tracing, authentication, and shear mental >>> overhead of what's going on. >>> >>> ~ David >>> >>> >>>> On Wed, Oct 14, 2020 at 8:55 AM Noble Paul <noble.p...@gmail.com> wrote: >>>> +1 @David Smiley >>>> >>>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya >>>> <ichattopadhy...@gmail.com> wrote: >>>> > >>>> > Maybe we need them for kerberos? I'm totally fine getting rid of >>>> > kerberos support from Solr core some day, but it might not be very easy >>>> > to refactor it into a package. >>>> > >>>> > On Sat, 10 Oct, 2020, 10:26 pm David Smiley, <dsmi...@apache.org> wrote: >>>> >> >>>> >> I think that historically, we are good at adding code but not good at >>>> >> removing code. We add new ways to do things but keep the old. Removal >>>> >> is more work often forgotten but doing nothing implicitly adds >>>> >> technical debt henceforth. >>>> >> >>>> >> With that segue... given that our latest SolrClient implementations are >>>> >> based on Jetty HttpClient (to support Http2 but should support 1.1?), >>>> >> do we need the original Apache HttpComponents/HttpClient as well? This >>>> >> is an honest question... maybe there are subtle reasons they are needed >>>> >> and I think it would be good as a project that we are clear on them. >>>> >> >>>> >> ~ David Smiley >>>> >> Apache Lucene/Solr Search Developer >>>> >> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> >>>> -- >>>> ----------------------------------------------------- >>>> Noble Paul
