The order of options involved in saving a style (via rest) can cause issues under certain auth patterns.
-Have 2 workspaces, ws1 and ws2
-Have 2 users, foo, with readwrite access to ws1 but not ws2; and bar, with readwrite access to ws2 but not ws1
-Have the REST /workspaces/*/styles endpoint accessible by ROLE_AUTHENTICATED
Steps to reproduce:
foo tries to edit a style in ws2 via REST
A 500 error will be returned, but the contents of the style will still be changed.
The problem can be seen here:
The contents of the style resource get changed before the style gets saved to the catalog. Since the Resource store doesn't have any security, this just happens. Then the StyleInfo is saved to the catalog, and there is failure due to security. However, the change has already been made to the resource, and doesn't get reverted.
There seem to be a few options for fixing this.
The most robust would be to have catalog security rules apply to the appropriate objects in the Resource store. This would almost certainly be a substantial api change, and worthy of a GSIP.
The simple solution would just be to attempt a save of the unmodified style immediately after receiving the request.