[
https://issues.apache.org/jira/browse/SOLR-18238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088517#comment-18088517
]
Utsav commented on SOLR-18238:
------------------------------
Was looking into this and this is the approach I came up with -
* Checked some V2 api endpoints and verified that validation today is ad-hoc
and inconsistent; some endpoints check for null only, some don't validate at all
* Rather than doing a per-endpoint validation that creates another thing to
add for all future and current endpoints, the idea is to add a framework-level,
"default-deny" validation layer for V2 path params
* Centrally enforced - any path parameter representing a resource identifier
is rejected with `400 Bad Request` if it's blank or whitespace-only
* An explicit, documented opt-out mechanism is provided for the rare case
where a blank path segment is intentionally meaningful
Open questions:
* Centralizing this check shifts validation out of individual endpoint methods
and into shared request-handling. Does that fit with how the project wants to
evolve the V2 API layer?
* Are there any endpoints currently that _tolerates_ blank path segments?
Query params are not considered for this effort. Can take it up a separate
effort
Would appreciate some insights into this. cc: [~epugh]
> Add Stronger Validation to V2 API Parameters
> --------------------------------------------
>
> Key: SOLR-18238
> URL: https://issues.apache.org/jira/browse/SOLR-18238
> Project: Solr
> Issue Type: Bug
> Components: v2 API
> Affects Versions: 10.0
> Reporter: Eric Pugh
> Priority: Minor
>
> We have very inconsistent validation across our V2 apis for things like
> pathParam and queryParams. For example, I recently discovered that in the
> ConfigSets API DELETE it would accept a " " as a configset name!
> It would be interesting to explore if we could have some validation that
> worked across our Java v2 apis, and maybe could also be used by the Solr UI
> as well.
>
> I can imagine:
> * Investigating the Jax RS Bean validation code.
> * Establishing much stronger patterns in our own Java API code that
> validates using the same util methods across all APIS (strong patterns make
> it easier for the next person to do the right thing)
> * Something around generating validation code in the OpenAPI spec generated
> language clients?
>
> This would be a great ticket for someone familiar with modern web dev
> techniques to contribute to Solr!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
