I don't see these goals as specifically linked to v2. Someone sloppily using GET inappropriately today (which happens all over the place, I'm aware) can and should stop. It's not unreasonable to fail such requests (GET requests performing modifications) in a minor release for better security. The underlying infra shouldn't have to do with v1 vs v2. I propose that the "read-only" constraint should be a first class property of the SolrQueryRequest. Any place where a new SQR is created must be updated carefully to propagate this—perhaps as a mandatory constructor argument. Same for the collection/alias scoping. It shouldn't matter if V2HttpSolrCall or HttpSolrCall builds the SQR. We'll need to ensure that both pieces info ride on federated requests somehow (e.g. shard fan-out is always POST but ought to articulate read-only somehow). Maybe HTTP headers.
On Wed, Sep 16, 2026 at 10:56 AM Eric Pugh <[email protected]> wrote: > I think this is a VERY feasible constraint that we could add to our V2 > apis. I know less about the query apis. I don't think we should worry > about the v1 APIs, they are what they are, and they should be retired. > > One way to make that happen is to add that explicitly to > https://github.com/apache/solr/pull/4826. As I'm going through V2 apis I > am referencing this document. It has also found other gaps like not all V2 > apis treat an error the same way. At some point we'll be able to review > all our V2 apis for "Do they all do things the same way", like GETs don't > mutate things. > > On Wed, Sep 16, 2026 at 9:55 AM Jan Høydahl <[email protected]> wrote: > > > Big +1 > > > > Some of these could even land in 10.x with a clear explanation why in > > upgrade notes. > > > > And the whole V1 API legacy also allows mutation on get, should start > > deprecating those and eventually remove as their V2 couterpart gets > stable. > > Don't need to graduate all V2 APIs in the same release. > > > > Jan > > > > > 16. sep. 2026 kl. 04:05 skrev David Smiley <[email protected]>: > > > > > > I have a wish-list I want to share for better security defaults. > Perhaps > > > Solr 11 if not sooner. > > > > > > (A) HTTP GET is purely read-only. The request is retry-able. Under no > > > circumstances, not even some delegating request, should a GET ever > result > > > in an index state mutation or a change to the cluster shape. For > example > > a > > > GET to /solr/coll/stream (streaming expressions) should be forbidden > from > > > using streaming expressions that update an index. > > > > > > Furthermore, some handlers (e.g. SearchHandler) may be > written/configured > > > to enforce read-only, even if POST is used (e.g. due to big queries). I > > > want to configure /stream handler as read-only but cannot do so today. > > > > > > (B) A collection-scoped request is isolated/firewalled to that > > collection. > > > A request to /solr/foo/whatever can only interact with the "foo" > > collection > > > (or any of its cores), or, if it points to an alias for multiple > > > collections, it must be scoped to those collections. I understand we > have > > > useful capabilities to break free, even to another cluster, but such > > > capabilities should be opt-in (i.e. an admin *must* _do something_ to > > allow > > > for that). The _something_ would be a solr.xml or sys-prop/env-var > > change, > > > NOT a configset change (at least not only). > > > > > > As we accomplish such aspirational goals, we then update the threat > model > > > https://github.com/apache/solr/blob/main/THREAT_MODEL.md > > <https://github.com/apache/solr/blob/main/THREAT_MODEL.md> > > > > > > The above two rules would allow an org to configure simple GET-only > > proxies > > > at certain paths and easily reason about what they are exposing. > > > > > > I'm tempted to create 11.0 blocker umbrella issues for both. > > > > > > > > > > > > > > > > > > > > > It's pretty remarkable what we allow, especially via streaming > > > expressions. A request to /solr/fooCollection/stream is in no way > scoped > > > to that collection. to use expressions that (A) write data (e.g. vi > > > to (A) mutate data (e.g. "update", expressions that communicate with > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > <http://www.linkedin.com/in/davidwsmiley> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > Disclaimer > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit > our website. >
