AH; I forgot about QUERY -- +1 to that! A good newdev ticket. On Thu, Sep 24, 2026 at 9:04 AM Jason Gerlowski <[email protected]> wrote:
> +1 to the general "aspirations" from David's initial email. > > On the v1 vs. v2 question, I think it's a matter of level-of-effort. > If there's bandwidth and energy to bring these ideals back to v1 and > we find creative backwards-compatible ways to do it - that's great! > But we're describing a decent amount of work here, and we as a > community aren't flush with bandwidth, so it may make sense to > prioritize the APIs we see sticking around longer-term. > > > 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. > > Have y'all seen the new "QUERY" Http method? I stumbled on this (I > think Ken L shared it somewhere) earlier this year, but it seems > tailor-made for replacing our "POST" usage in SearchHandler: > https://www.rfc-editor.org/info/rfc10008/ > > Best, > > Jason > > On Wed, Sep 16, 2026 at 11:30 AM David Smiley <[email protected]> wrote: > > > > 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. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
