A user that has edit access to an application, but not one of the resources in that application can still trigger queries from that Resource.
Steps to reproduce:
- Create an application and give it a resouce
- Have a user that has edit access to that application, but not the resource
- This user does not have permission to edit anything in the application due to not having access to this resource, this is good to prevent them from breaking anything they shouldn't.
- The user can select the resource they do not have access to, modify it in any way, then click preview (which runs it their new version of the query). This can be an issue if someone less technical removes the WHERE statement on an UPDATE query and click "Preview".
Expected Outcome:
The user cannot modify a query (and then run that modified version of the query) of a resource they do not have access to in any way while in edit mode on an application.
Desired Outcome:
The user cannot modify a resource (and then run that modified version of the query) they do not have access to in any way while in edit mode on an application, but can still modify/edit resources they do have access to as well as elements in that application.
View of user that has edit access to the application, but not the resource after running the preview.
Hey @Jay_Walters! If a user has edit access to an app, then they have edit access to queries in that app. Not granting edit access to the resource means that they can't change the resource setup at all. If they have use access, then they can write and modify queries that use that resource in apps where they have edit access.
Can you share the permissions that you have set up here?
For the above I created a new permission "Test" and gave it edit access to the application "Verification Test" and nothing else.
Here is an image of the permissions that the user we used to test this had.
Through experimentation the user cannot save any changes in the application as they do not have access to the Resource that Query2 uses in my above screenshot. The issue is they can still modify the text of the query and by using the "Preview" button run that modified query, despite not having access to the resource. I have not yet experimented to find out if it will still allow a delete, but did find that a user with this permission set can modify the table/columns the query using this method to get data that they shouldn't have access to.
I'll add that we are self hosted and currently on 3.10.X.
If this is the desired outcome of this interaction I can work around it, our use case is likely not standard (Non IT developers that don't have access to delete/insert resources whose projects go to my team to review/add those resources).
@Jay_Walters Thanks for the extra detail, I misread initially and assigned use access to the resource. Can you share what version you are on? Is this a cloud account or self hosted?
Tested on cloud and a user with edit permissions on an app, and no permissions on any resources cannot run (or preview queries). But happy to take a look at a specific self hosted version as well.
Sorry for the late reply. It does seem it prevents the user from accessing anything in the database still, but doing something like SELECT "test" does still work (which doesn't matter as they aren't accessing any data they shouldn't).
