Bug: Value-based permission checks do not roll back changes to the StreamModule

[robere2]

Normally, when a user mutates an object in the API, the flow looks something like this:

• User submits request (Let's say it's a createUser request for this example)
• API makes sure user has permission to create users
• API makes sure user has permission to create all the fields supplied on Users
• API creates the User via a Prisma transaction
• API makes sure the user has permission to create the specific User object, with values, returned by Prisma.
• If user has permission, the transaction is committed. If the user doesn't have permission, the transaction is rolled back.

With streams, they are not published through Prisma. This means that even if a user's value-based permission checks fail, the stream will still be created, as there is nothing to roll back. In other words, by the time the API checks if the user has permission to create the specific stream they are trying to create, it has already been sent off to the glimpse-video-control service for creation.

As an example, consider a user who has permission to stream with a to value pointing to youtube.com but not facebook.com. When the API checks the user's permissions, it only makes sure that the user has permission to use the to value before sending the value to the glimpse-video-control service. Later, the API will determine that the user doesn't have permission to send to facebook.com, but at that point it is too late, since the request has already been sent and there is no "rollback" feature.

This is not a major issue, since it only applies to modules which don't use the Prisma transaction (at the moment, only the StreamModule, which in our use-case does not have conditional permissions like this at the moment). A more general-purpose rollback mechanism should perhaps be created during the inevitable StreamModule rewrite.

[robere2]

Note: The reason we do not check permissions before creating them is because services (i.e. Prisma) may generate or change the values supplied. We want to include these generated values in our permission checks.