[API] Internal DB IDs used as parameters
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 1.4k
- Avg merge
- 6d 19h
- Merged PRs (30d)
- 32
Description
##### ISSUE TYPE
* Improvement Request
##### COMPONENT NAME
~~~
API
~~~
##### CLOUDSTACK VERSION
~~~
Any
~~~
##### CONFIGURATION
N/A
##### OS / ENVIRONMENT
N/A
##### SUMMARY
The API accepts internal database IDs as well as UUIDs on the UUID parameters. For example:
````
(nvs) 🐱 > list accounts id=c3d932e5-488c-11ef-a188-3e7340e5df3c filter=id,name
{
"account": [
{
"id": "c3d932e5-488c-11ef-a188-3e7340e5df3c",
"name": "nicolas"
}
],
"count": 1
}
(nvs) 🐱 > list accounts id=2 filter=id,name
{
"account": [
{
"id": "c3d932e5-488c-11ef-a188-3e7340e5df3c",
"name": "nicolas"
}
],
"count": 1
}
(nvs) 🐱 > list accounts id=3 filter=id,name
{
"account": [
{
"id": "eef0d0a3-8013-4c37-954d-eafb96716c95",
"name": "baremetal-system-account"
}
],
"count": 1
}
````
##### EXPECTED RESULTS
~~~
ERROR - only UUIDs must be accepted
~~~
##### ACTUAL RESULTS
~~~
Successful API response
~~~
Contributor guide
Research direction
Start by reproducing the documented list accounts calls with id set to a UUID, 2, and 3, then trace the API parameter validation and lookup path for UUID parameters. Done means numeric internal database IDs are rejected with an error while valid UUIDs continue to return the account.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100