It’s a problem with Chrome =\ I have emptied cache/cookies, closed all windows, and restarted Chrome, multiple times – but found that Chrome is still sending a basic auth header, which passes authorization. The weird thing is that the Solr Admin panel never shows me as logged in.
I opened an incognito tab and accessed Solr, the basic auth prompts me. Bottom line – This is a Chrome problem, not Solr. Jeremy Branham [email protected]<mailto:[email protected]> From: "Branham, Jeremy (Experis)" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Monday, March 18, 2019 at 8:57 AM To: "[email protected]" <[email protected]> Subject: [External] Re: Re: Re: Authorization fails but api still renders Thanks Martin, but I don’t see how this could be a DNS issue. These are remote clusters/nodes that only have 1 public [internal network] IP and the hostname and FQDN both resolve to that IP. I can access Solr fine using either, or even the IP. The problem is that authorization is skipped in Solr when I use the short hostname to access the server. Jeremy Branham [email protected]<mailto:[email protected]> From: Martin Gainty <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Sunday, March 17, 2019 at 6:31 AM To: "[email protected]" <[email protected]> Subject: [External] Re: Re: Authorization fails but api still renders Jeremy- the problem is your DNS lookup algorithm/service as a test add the missing FQDN to etc/hosts..as a test I would add "localhost" to 192.168.1.1<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.1.1&d=DwQF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=QuIwnegZIF-DJYqQTKLocihCDzZOHqaRf0cKbHPWs5c&e=> https://www.linuxquestions.org/questions/slackware-14/hostname-fqdn-etc-hosts-setup-302189/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linuxquestions.org_questions_slackware-2D14_hostname-2Dfqdn-2Detc-2Dhosts-2Dsetup-2D302189_&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=Qg5IOIboRxf5wolBqW2kW8ogOw4CDa_f_yRaZxrmyn4&e=> [age removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linuxquestions.org_questions_slackware-2D14_hostname-2Dfqdn-2Detc-2Dhosts-2Dsetup-2D302189_&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=Qg5IOIboRxf5wolBqW2kW8ogOw4CDa_f_yRaZxrmyn4&e=> hostname, fqdn, /etc/hosts setup - linuxquestions.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linuxquestions.org_questions_slackware-2D14_hostname-2Dfqdn-2Detc-2Dhosts-2Dsetup-2D302189_&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=Qg5IOIboRxf5wolBqW2kW8ogOw4CDa_f_yRaZxrmyn4&e=> Introduction to Linux - A Hands on Guide This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter. www.linuxquestions.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linuxquestions.org&d=DwQF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=0-5zzAvVFm8uYxiGOrTbvTeSAD4zWXdFHH0lFgqEngc&e=> if that works then populate etc/BIND or whatever nameserver-lookup service that resolves FQDN https://serverfault.com/questions/18748/overriding-some-dns-entries-in-bind-for-internal-networks<https://urldefense.proofpoint.com/v2/url?u=https-3A__serverfault.com_questions_18748_overriding-2Dsome-2Ddns-2Dentries-2Din-2Dbind-2Dfor-2Dinternal-2Dnetworks&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=7JxODGQk9XNuSUG1DkUWr2Pal7nc7ailf9UKmLLbdTg&e=> [age removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__serverfault.com_questions_18748_overriding-2Dsome-2Ddns-2Dentries-2Din-2Dbind-2Dfor-2Dinternal-2Dnetworks&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=7JxODGQk9XNuSUG1DkUWr2Pal7nc7ailf9UKmLLbdTg&e=> Overriding some DNS entries in BIND for internal networks - Server Fault<https://urldefense.proofpoint.com/v2/url?u=https-3A__serverfault.com_questions_18748_overriding-2Dsome-2Ddns-2Dentries-2Din-2Dbind-2Dfor-2Dinternal-2Dnetworks&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=7JxODGQk9XNuSUG1DkUWr2Pal7nc7ailf9UKmLLbdTg&e=> Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.. Visit Stack Exchange serverfault.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__serverfault.com&d=DwQF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=CJPMxlk4Kk2n0a8C55jV8g5lQMZKdb5PsquSbz8R_T0&e=> restart BIND service and restart lucene and test your localhost HTH ________________________________ From: Branham, Jeremy (Experis) <[email protected]> Sent: Friday, March 15, 2019 10:18 AM To: [email protected] Cc: [email protected] Subject: Re: Re: Authorization fails but api still renders // Adding the dev DL, as this may be a bug Solr v7.7.0 I’m expecting the 401 on all the servers in all 3 clusters using the security configuration. For example, when I access the core or collection APIs without authentication, it should return a 401. On one of the servers, in one of the clusters, the authorization is completely ignored. The http response is 200 and the API returns results. The other server in this cluster works properly, returning a 401 when the protected API is accessed without authentication. Interesting notes – - If I use the IP or FQDN to access the server, authorization works properly and a 401 is returned. It’s only when I use the short hostname to access the server, that the authorization is bypassed. - On the broken server, a 401 is returned correctly when the ‘autoscaling suggestions’ api is accessed. This api uses a different resource path, which may be a clue to why the others fail. https://solr:8443/api/cluster/autoscaling/suggestions<https://urldefense.proofpoint.com/v2/url?u=https-3A__solr-3A8443_api_cluster_autoscaling_suggestions&d=DwMF-g&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=D9xr-kHadkbwzgxr54XLS8yN4Tq_vCsVP2jiWCiRyfk&s=R_T6fJz0fXG7e7DfaIRZA2zwj8JcySBtU31SenrjuZs&e=> Here is the security.json with sensitive data changed/removed – { "authentication":{ "blockUnknown": false, "class":"solr.BasicAuthPlugin", "credentials":{ "admin":"--REDACTED--", "reader":"--REDACTED--", "writer":"--REDACTED--" }, "realm":"solr" }, "authorization":{ "class":"solr.RuleBasedAuthorizationPlugin", "permissions":[ {"name":"security-edit", "role":"admin"}, {"name":"security-read", "role":"admin"}, {"name":"schema-edit", "role":"admin"}, {"name":"config-edit", "role":"admin"}, {"name":"core-admin-edit", "role":"admin"}, {"name":"collection-admin-edit", "role":"admin"}, {"name":"autoscaling-read", "role":"admin"}, {"name":"autoscaling-write", "role":"admin"}, {"name":"autoscaling-history-read", "role":"admin"}, {"name":"read","role":"*"}, {"name":"schema-read","role":"*"}, {"name":"config-read","role":"*"}, {"name":"collection-admin-read", "role":"*"}, {"name":"core-admin-read","role":"*"}, {"name":"update", "role":"write"}, {"collection":null, "path":"/admin/info/system", "role":"admin"} ], "user-role":{ "admin": "admin", "reader": "read", "writer": "write" } }} Jeremy Branham [email protected] On 3/14/19, 10:06 PM, "Zheng Lin Edwin Yeo" <[email protected]> wrote: Hi, Can't really catch your question. Are you facing the error 401 on all the clusters or just one of them? Also, which Solr version are you using? Regards, Edwin On Fri, 15 Mar 2019 at 05:15, Branham, Jeremy (Experis) <[email protected]> wrote: > I’ve discovered the authorization works properly if I use the FQDN to > access the Solr node, but the short hostname completely circumvents it. > They are all internal server clusters, so I’m using self-signed > certificates [the same exact certificate] on each. The SAN portion of the > cert contains the IP, short, and FQDN of each server. > > I also diff’d the two servers Solr installation directories, and confirmed > they are identical. > They are using the same exact versions of Java and zookeeper, with the > same chroot configuration. [different zk clusters] > > > Jeremy Branham > [email protected] > > On 3/14/19, 10:44 AM, "Branham, Jeremy (Experis)" <[email protected]> > wrote: > > I’m using Basic Auth on 3 different clusters. > On 2 of the clusters, authorization works fine. A 401 is returned when > I try to access the core/collection apis. > > On the 3rd cluster I can see the authorization failed, but the api > results are still returned. > > Solr.log > 2019-03-14 09:25:47.680 INFO (qtp1546693040-152) [ ] > o.a.s.s.RuleBasedAuthorizationPlugin request has come without principal. > failed permission { > "name":"core-admin-read", > "role":"*"} > > > I’m using different zookeeper clusters for each solr cluster, but > using the same security.json contents. > I’ve tried refreshing the ZK node, and bringing the whole Solr cluster > down and back up. > > Is there some sort of caching that could be happening? > > I wrote an installation script that I’ve used to setup each cluster, > so I’m thinking I’ll wipe it out and re-run. > But before I do this, I thought I’d ask the community for input. Maybe > a bug? > > > Jeremy Branham > [email protected]<mailto:[email protected]> > Allstate Insurance Company | UCV Technology Services | Information > Services Group > > > >
