Thank you for starting this discussion.
Currently parameters work by using the query text as a template and merging the parameters values into it when running the query. This is not safe and prone to SQL injections (by definition). For this reason we don’t support parameters in embeds or shared dashboards.
The use case you describe is a bit different, as you want to preset the parameters values, which makes the threat of SQL injections irrelevant as the person who assigns the parameter values is a trusted person who has access to the data.
The way share dashboards work is that we create an API Key object that has access to a given dashboard:
So this is how we currently generate a shared dashboard URL.
To bind a shared dashboard URL with a list of parameters we have two options (I can think of):
- We can store along with the API Key a list of parameter values that are allowed to be used with this API Key.
- Have the concept of a public API key and a private one. The public API key will be used to reference the dashboard and as a way of creating a random URL. The private API key will be known only to the system and will be used to sign the URL with a specific set of parameters.
The benefit of #1 is its simplicity and security (no way for an outside user to alter the list of values). The benefit of #2 is that we don’t have to create a database record for each set of parameters.
The next issue is how to load the data. Currently the public dashboard API returns the dashboard data along with the query results in one API call. To be able to run queries with parameters and utilize current APIs it’s best if we implement support in current Query Results API to deduce whether the current call is allowed based on the dashboard API key = if the dashboard has this query & the parameters are in the allowed list.
That’s a lot of text I hope it all makes sense, please let me know if you have further questions and what are your thoughts.