[
https://issues.apache.org/jira/browse/SOLR-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-18170:
-----------------------------
Labels: V2 api configset newdev (was: V2 api configset)
> Invalid Create Configsets API validation
> ----------------------------------------
>
> Key: SOLR-18170
> URL: https://issues.apache.org/jira/browse/SOLR-18170
> Project: Solr
> Issue Type: Bug
> Components: configset-api, v2 API
> Affects Versions: 10.0
> Reporter: Christos Malliaridis
> Priority: Major
> Labels: V2, api, configset, newdev
>
> h3. Description
> After testing the Configsets Create API I noticed that the API is not
> properly validating the received data and sometimes even allow the creation
> of configsets with invalid names.
> According to an error of the Admin UI, it is {*}assumed that configsets
> follow the same naming pattern as the collections{*}, and therefore should
> - configset names *must* consist entirely of periods, underscores, hyphens,
> and alphanumerics
> - configsets *must* not start with a hyphen
> However, there is no clear naming rules defined anywhere (at least from what
> I could find) for the configsets. Therefore, they should likely follow the
> same rules as collection names and core names.
> h3. Test Cases
> The endpoints that were used for the test cases below are:
> * for v1
> [http://localhost:8983/solr/admin/configs?action=CREATE&name=[configsetname]]
> * for v2 [http://localhost:8983/api/configsets] (with json request body)
> When creating configsets with invalid configset names via the AdminUI an
> error is shown immediately that say
> {quote}Invalid collection: [._designer_ads""]. collection names must consist
> entirely of periods, underscores, hyphens, and alphanumerics as well as not
> start with a hyphen.
> {quote}
> but the configset is created successfully, which gives the impression that
> all these cases are actually not "invalid", but the different behavior
> between APIs seems that they are just not validated correctly. The below
> table shows a list of configset names, the expected responses when applying
> the same collection name rules, and the responses from v1 and v2 API.
> ||Configset Name||Expected Response||v1 Behavior||v2 Behavior||
> |configset!|400|200
> _configset "configset!" created_| 200
> _configset "configset!" created_|
> |test%2F..%2Fother
> (escaped test/../other)|400|500
> Invalid path string \"/configs/test/../other\" caused by relative paths not
> allowed @15|200
> _configset "test%2F..%2Fother" created_|
> |test/../other
> (unescaped)|400|500
> Invalid path string \"/configs/test/../other\" caused by relative paths not
> allowed @15|500
> Invalid path string \"/configs/test/../other\" caused by relative paths not
> allowed @15 |
> |configset\"
> (unescaped)|400|200
> _configset "configset\"" created_|200
> configset "configset\"" created|
> |configsets%5C%22
> (escaped configsets\")|400|200
> _configset "configset\"" created_|200
> _configset "configsets%5C%22" created_|
> |-configset
> (prefixed with -)|400|200
> _configset "-configset" created_|200
> _configset "-configset" created_|
>
> Using invalid names often leads to strange errors in the Admin UI, as they
> are usually strongly coupled with collection names that come with some
> validation.
> Additionally, according to documentation, the base configset is optional, but
> in the v2 API it is mandatory. Setting the "baseConfigSet = null" leads to a
> 400 response, and setting it to an empty string results to a 500 server error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
