How to stop URL change to dashboard variable query response

Grafana
1

Hi all, I’m using a dashboard variable query to a SimpleJson datasource to return a list of ‘groups’ that are in scope for a particular Grafana user (Viewer), identified by their ApiKey passed using the X-DS-Authentication header. That bit works fine and the list of allowed groups (say 1,4 and 5) appears in the dropdown list for the variable. I then use the same variable in a SQL command via the Postgres datasource to return a timeseries based on the selected group. That’s great but the value of my variable appears in the URL, and there’s nothing to stop the user choosing another group ID that’s not in scope, thereby gaining access to someone else’s data, eg, randomly pick group 6

https://myserver.com:3000/d/zWbySTnik/cpu-dashboard?orgId=1&var-GetValidGroups=6

What can I do to prevent the variable being shown in the URL, and more importantly, to make sure that only values returned by the variable query response are deemed valid in the Postgres datasource?

2

There is nothing you can do about this . Datasource queries are build and send by the browser and can always be modified by a user who knows HTTP (even if the variable values are in URL or not).

The only way to get data isolation and security is to have different Grafana data sources in different Grafana organizations. Then each datasource you need to configure a sql user that only is alllowed to query the data you want to expose to that user (via sql permissions)

1 Like
3

Thanks for the quick reply! Ah, so you’re saying create each user in their own organization (I can do this by basing the AuthProxy on the email, rather than at present where I deliberately base it on a fixed username). I’ll play with this configuration, although given that the orgId is also in the URL, I guess a curious user can just select another orgId, and hence still see the data for another user, circumventing the SQL permissions?

I also came across this link, Grafana templating by logged in user. I hadn’t thought about using dashboard folders. Could these help for my use case?

My fallback is to use our SimpleJson datasource for everything since this is served by a Golang backend where we can use the user ApiKey passed in a HTTP header to differentiate the users, and then make Postgres SQL queries within Go code. It would be so much nicer though to write the SQL queries in the Grafana Postgres datasource