dotted user names and hosts are truncated

[Ed Cranford]

If a username or host in a user CRUD call has a dot in it, it gets truncated and serves 404s for the new shortened identifier.
In the worst case scenario, users could be modifying the wrong user should there happen to be a real user identified with the shortened field.

Setup:
curl -i http://trove.example.com/v1.0/tenant_id/instances/instance_id/users
HTTP/1.1 200 OK
{
  "users": [
    {
      "databases": [],
      "host": "127.0.0.1",
      "name": "example"
    }
  ]
}

Expectation:
curl -i http://trove.example.com/v1.0/tenant_id/instances/instance_id/users/example@127.0.0.1
HTTP/1.1 200 OK
{
  "user": {
    "databases": [],
    "host": "127.0.0.1",
    "name": "example"
  }
}

Reality:
curl -i http://trove.example.com/v1.0/tenant_id/instances/instance_id/users/example@127.0.0.1
HTTP/1.1 404 Not Found
{
  "itemNotFound": {
    "code": 404,
    "message": "User example@127.0.0 cannot be found on the instance."
  }
}

I'm aware that this is the accepted workaround:
curl -i http://trove.example.com/v1.0/tenant_id/instances/instance_id/users/example@127%252e0%252e0%252e1
HTTP/1.1 200 OK
{
  "user": {
    "databases": [],
    "host": "127.0.0.1",
    "name": "example"
  }
}

But it's admittedly a little surprising to a lot of API users, and I bet I could swing it so that the Expectation works without disrupting the rest of the API's behavior.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/56966

[Sam Harwell (sam-z)]

The "workaround" listed in the original description actually requests the removal of a user at the host 127%2e0%2e0%2e1, which is not a valid host address. The behavior of the current service requires twice percent encoding periods in names, which is directly opposed to RFC 3986 §2.3.

In addition, the documentation does not specify what the allowed set of code points is for a username or database name. It does however specify that the database instance is MySQL, so a developer could easily and reasonably infer that `%`, `2`, and `e` are all valid characters in a name. The current implementation would take the valid name `MyData%2e` and turn it into `MyData.`.

[Brian Hartsock (brian-hartsock)]

I'm all for fixing this behavior. From a client perspective, it is not intuitive and requires documentation to understand. Also, no standard URL library works this way so it requires custom code just for this API.

I would expect the following:

example@127.0.0.1 to encode to .../example@127.0.0.1 since . and @ are both allowed in this part of the URL without encoding.

example@127.% to encode to .../example@127.%25 since % must be encoded.

[Zack Shoylev (zack-shoylev)]

I want to add a +1 for fixing this bug. The behavior is not intuitive, and requires extra code to be supported. URI specs should be followed.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/56966
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=da22a01ecbde6b81f4a23c5e12daa8617f617f2f
Submitter: Jenkins
Branch: master

commit da22a01ecbde6b81f4a23c5e12daa8617f617f2f
Author: Ed Cranford <email address hidden>
Date: Fri Nov 15 11:43:44 2013 -0600

    Extract suffix from req URL to avoid escaping dots

    Usernames and their hosts can contain dots. As such,
    user CRUD requests may end in ids that contain one
    or more fullstops. Our request router can interpret
    these as file suffixes and our methods and as a
    result, truncates these ids improperly.

    This change inspects the request object in these
    cases, looks for a possibly misinterpreted suffix,
    and reattaches the suffix to the id. This means
    that escaping . in requests shouldn't be necessary.

    Closes-Bug: #1252327

    Change-Id: I74c4d6694baba44ebe0018eedac2ae5c4773b370