[API] Internal DB IDs used as parameters

[nvazquez]

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

[DaanHoogland]

@nvazquez isn't this just very convenient for admins? they have to look at the db and it would be very usefull for them to be able to use the DB ID instead of the UUID, at times. I can understand if we disable this for other users but would really like to keep the behaviour in for admins.

[shwstppr]

@nvazquez @DaanHoogland how about a global config to control the behaviour? Only pre-3.x (or the ones missing since annotation) APIs would allow internal DB IDs. I created a PR to control this. Default behaviour would continue

[DaanHoogland]

yout PR looks good @shwstppr , I wonder though if we should only allow root admin to use the old behaviour?

[shwstppr]

@DaanHoogland Root admin filter makes sense. But since will add an additional DB call to check the caller for each API/param I would want something like to keep track of the caller, #11390