[
https://issues.apache.org/jira/browse/SOLR-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christos Malliaridis updated SOLR-18170:
----------------------------------------
Description:
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.
was:
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.
> 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
>
> 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]
