REST v2: on update entity field (PUT) response is OK for restUser without permission

ver: 6.6-SNAPSHOT

Steps to reproduce:

  • Create a restUser with read-only permission on an Entity Attribute

  • Use PUT to update the Entity Attribute

  • you get a [200] response but the Attribute is not updated

Well, it works this way right now. We’ll discuss, maybe this behavior should be changed. The issue: https://youtrack.cuba-platform.com/issue/PL-9968

1 Like

Hi Max thanks for the reply,

I think fine-graining rest user permissions is important for security.

This is where the error came up, I forgot to give the right permission to the attribute I wanted the restUser to update…

I think debugging this could be difficult if no error is raised, unless one checks the response content every time

Hi,

one could argue that could find if an attribute has been updated or not, simply by comparing the request body with the response one.

But there is a fundamental problem with the PUT verb assumptions: PUT method is idempotent. So if you send retry a request multiple times, that should be equivalent to single request modification.

That stops to be true when the result of the operation could change based on dynamic factors, like permissions.
So, in that regard, a PUT operation should succeed completely or fail completely.

IMHO a partial PUT operation should not be allowed, and a 403 - forbidden response should be returned instead.

Just my 2c…
Paolo

Hi Paolo,

Thanks for the reply. I’m not sure I got the point completely, what do you mean by “partial PUT”?

Do you think the rest User should be given always full Update permissions on Entities it needs to update just some attributes of? And be forced to Update all the Entity attributes?

@lucio.rossi75

no, I mean that the REST API should either update all the attributes given in the request, or fail completely.

HTTP verbs should follow some common-sense rules, and one of them is that a PUT operation should:

  • be idempotent, that is if you send the same request, the result should be always the same, and not depending on dynamic factors
  • replace all the attributes of a resource, and if some attributes are missing, they should be reset/deleted (in our case, set to null)
  • as a consequence of idempotence, the response of a PUT request should be cacheable by the client, because there is the assurance that for the same request there will always be the same response

In this case, CUBA is violating the first rule, because if you have an existing entity with

{
name: 'my name'
}

and you send a PUT with

{
name: 'another name'
}

and the user does not have update permission on name, it will return:

{
name: 'my name'
}

then an administrator, a minute later, gives the user update permission on name, and if the client repeats the above PUT request it will have this response:

{
name: 'another name'
}

thus violating the idempotence rule… if the client has cached the previous response, your app now is broken.

So CUBA should return a 403 error when trying to update attributes the user is not permitted to.
Failing to do so is a bug, and not simply an implementation detail…

Hope this clarify my previous comment.
Paolo

1 Like

@pfurini
It is clear now,
thank you!