application.get: Add support for retrieving applications by uuid

[thgreasi]

Originally draft just b/c I still haven't added tests.

Resolves: #1016
Change-type: minor
Signed-off-by: Thodoris Greasidis thodoris@balena.io

---

Contributor checklist

• Includes tests
• Includes typings
• Includes updated documentation
• Includes updated build output

[thgreasi]

This is essentially the only code change.

[pdcastro]

To confirm, this only accepts "long" or "full" UUID, right? Not something like decade2 which is a valid 7-char short UUID. (I think that accepting short UUIDs here would be bad, creating more ambiguity that goes in the opposite direction of the spirit of #1030.) By the way, we discussed before (not necessarily decided, at least discussed) that there should be a way for the SDK to allow the caller (CLI/UI/user app) to query specifically and unambiguously by UUID or slug or name or ID, instead of nameOrSlugOrUuidOrId. For example, instead of:

    nameOrSlugOrUuidOrId: string | number

Perhaps it could be:

    nameOrSlugOrUuidOrId: string | number | object

And if it was an object, the object would be exactly one of:

• { id: number }
• { uuid: string }
• { name: string }
• { slug: string }

But, fair enough, a long / full UUID can be assumed to never legitimately clash with an unintended resource. I say "legitimately" because a bad user could copy and paste the UUID of an app and set it as the name of another app, in which case this query would be "illegitimately ambiguous" when nameOrSlugOrUuidOrId was a string.

[pdcastro]

Or maybe not that harmless... A bit far fetched and just hypothetical, but could user A create a sort of denial of service attack on user B by creating an app that was named after the UUID of one of user B's apps? User A could become aware of the UUID of an app of user B for being a collaborator / observer of that app.

Or, what about public apps? If the UUID of a public app is public, could I create a DoS attack on the public app by naming another public app (of mine?) after that UUID? Such that people's query for the legit UUID would return my illegit app (by name) instead. I haven't tested, just hypothetical.

[thgreasi]

Yes it only accepts full UUIDs, for the reasons you mentioned.
I did have in mind the | AlternateKeyObject, but decided to not implement it in this PR, since I wouldn't want to also support names in that notation, since technicaly the name is not an alternate key (aka table wide natural key).

The denial of service scenario you describe is already possible by having user B name their app with the same name as user A. But user A can in that case use the app slug. This is going to be fully resolved though with #1030.

[thgreasi]

@pdcastro let me know if you would prefer to not merge this before the next major where we drop support for retrieving apps by name in this method.

[pdcastro]

The denial of service scenario you describe is already possible by having user B name their app with the same name as user A. But user A can in that case use the app slug.

Is it really the same thing? The case of clashing names (multiple apps with the same name) can be resolved by using the app slug which the recommended practice, but for the scenario I described, querying by app UUID does not solve the problem -- and to say "use the slug instead of the UUID" sounds like a design failure. It sounds like we are saying that querying by app UUID could be ambiguous, an ambiguity being introduced by this PR / solution.

if you would prefer to not merge this before the next major

I'm not worried about that, but I am worried about ambiguity when querying by UUID. I'd rather this PR implemented a solution where querying by UUID could not possibly be ambiguous, or subject to DoS.

[thgreasi]

@balena-ci I self-certify!