get sql-based Domain-specific driver configuration with incorrect group in URL, expected response 404, actual 403

[Thomas Hsiao]

get sql-based Domain-specific driver configuration with incorrect group in URL, expected response 404, actual 403:

With sql-based Domain-specific driver configuration set up connection to a openldap or ad backend for a domain,
if an invalid/typo group name (e.g. [identity2], instead of [identity]) in the request url for this domain is provided, we expect the response code 404 (not found), but actual is 403 (forbidden). The user actually has the permission to access the configuration. 403 forbidden seems misleading.

Example:
~$ curl -k -H "X-Auth-Token:ADMIN" -XDELETE http://localhost:35357/v3/domains/6a006689702640ba92d5e536b238e893/config/invalidgroup

Actual:
{"error": {"message": "Invalid domain specific configuration: Group identity2 is not supported for domain specific configurations", "code": 403, "title": "Forbidden"}}

Expected:
~$ curl -k -H "X-Auth-Token:ADMIN" -XDELETE http://localhost:35357/v3/domains/6a006689702640ba92d5e536b238e893/config/identity2
{"error": {"message": "Invalid domain specific configuration: Group identity2 is not supported for domain specific configurations", "code": 404, "title": "Not Found"}}

[Steve Martinelli (stevemar)]

I'm not sure about this one, how do we "look up" the configuration group?

Looks like the author picked 403 deliberately: https://github.com/openstack/keystone/blob/master/keystone/exception.py#L248-L249

[Thomas Hsiao (thomas-hsiao)]

Hi Steve,
Understood the hesitation on this. Either 403 or 404 has its point.
The reason I logged this bug, just because I though 404 would make more sense on the logic and meaning.

Assume a user has the permission to access the ldap config.
He made a request to look up the config group or options.
He just a typo on the group.
I think he would expect 404 "Not found" instead of 403 "Forbidden".

Another example that I believe the current Keystone responses correctly with 404 "Not Found" with typo in the url:
1. Typo on domain id:
curl -k -H "X-Auth-Token:ADMIN" http://localhost:35357/v3/domains/2824c34569fb4def8cb1e2e3fe4bd4ec56/config
{
    "error": {
        "code": 404,
        "message": "Could not find any options in domain configuration for domain 2824c34569fb4def8cb1e2e3fe4bd4ec56",
        "title": "Not Found"
    }
}

2. Typo on resource name
curl -k -H "X-Auth-Token:ADMIN" http://localhost:35357/v3/domains/60e966230a654eeb872bb0972678c5fb/helloconfig
{
    "error": {
        "code": 404,
        "message": "The resource could not be found.",
        "title": "Not Found"
    }
}

Therefore, I propose that typo on the group name or option name should response 404 "Not Found" as well for consistency as below. 403 "Forbidden" should be specific for "permission" rejected conditions.

curl -k -H "X-Auth-Token:ADMIN" -XDELETE http://localhost:35357/v3/domains/6a006689702640ba92d5e536b238e893/config/identity2
Expected:
{"error": {"message": "Invalid domain specific configuration: Group identity2 is not supported for domain specific configurations", "code": 404, "title": "Not Found"}}

[Guang Yee (guang-yee)]

Steve, if user have no access to the API, regardless if the target resource exist or not, 403 should be returned. On the other hand, if user have access to the API and the target resource does not exist, then 404 is appropriate.

[Steve Martinelli (stevemar)]

Guang, but a config option is not a resource. It's a part of the update/create request. Either way, I'm not eager to change an API response given that the error message is pretty good. I'll mark this as wishlist.

[Steve Martinelli (stevemar)]

Automatically unassigning due to inactivity.

[Steve Martinelli (stevemar)]

No movement on this issue and I've explained my reasoning in comment #4. We won't be re-writing response codes now since that's backwards compatible.