Please see the default security.json template that ships with solr and that is activated whenever you activate basicAuth from bin/solr auth command.
https://github.com/apache/solr/blob/main/solr/core/src/resources/security.json As you see, we first define the common admin permissions, then open up health and metrics-read by saying "null", and finally a catch-all "all" entry that require an admin user. Difference from Craig's solution is that this uses the built-in named permissions <https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html#predefined-permissions> rather than defining your own paths on the fly. Which is more robust and it automatically covers both v1 and v2 paths as well. Jan > 26. okt. 2026 kl. 16:31 skrev Oakley, Craig (NIH/NLM/NCBI) [C] via users > <[email protected]>: > > Assuming you are using security.json (as described in > solr.apache.org/guide/solr/latest/deployment-guide/basic-authentication-plugin.html), > what we do is add a line at the beginning of the authentication section: > "authentication":{ > "blockUnknown":false, > ... > > We also assign a role to every user (in this example, the role is named > allgen) > > And then toward the end of the authorization section, we have a clause which > specifically allows select without any role ("role":null) followed by > catch-all clauses to require the allgen role for anything else: > ... > { > "name":"open_select", > "path":"/select/*", > "role":null, > "index":23}, > { > "name":"catch-all-nocollection", > "collection":null, > "path":"/*", > "role":"allgen", > "index":24}, > { > "name":"catch-all-collection", > "path":"/*", > "role":"allgen", > "index":25}, > { > "name":"all-admincol", > "collection":null, > "path":"/admin/collections", > "role":"allgen", > "index":26}, > { > "name":"all-admincores", > "collection":null, > "path":"/admin/cores", > "role":"allgen", > "index":27}], > ... > > -----Original Message----- > From: Dmitri Maziuk <[email protected]> > Sent: Monday, October 12, 2026 1:16 PM > To: [email protected] > Subject: [EXTERNAL] allow unauthenticated search > > Hi all, > > as per the subject: can we allow unauthenticated search and ping/health > but require auth for any modifications? I am not quite seeing it the The > Fina Manual and AI overlords aren't helpful either. > > TIA > Dima > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and are confident > the content is safe. >
