Add server-side parameter handling for embeds

[whummer]

Hey @arikfr,

This is an updated pull request fulfilling #929, taking a slightly different approach than our previous PR (#995). Instead of retrieving the query template and filling in the parameter on the client side, this code receives the parameters and renders the query template on the server side (via pystache.render) and then returns the result.

It seems that this is a much simpler approach which integrates nicely with the existing embed.html. It is potentially also safer because the SQL query is not exposed to the client. SQL injection is still a potential threat, though, therefore we keep a warning message in the settings.py and disable this feature by default.

In general, it seems that other parts of the framework are also affected by potential SQL injection (e.g.,QueryResultListResource::post uses plain parameters). As part of a future work item, maybe we could use a proper SQL templating engine to prevent SQL injection altogether. However, for our current use cases this solution is sufficient (it is used mostly internally).

Please let us know what you think. Thanks

[arikfr]

I don't want to introduce synchronous execution of queries with current implementation, as it will lead to some long running queries choking the frontend making the system unresponsive. I do want to introduce it in the future when we make the API server async (either by utilizing gevent or some other way).

Adding non standard query execution way makes this pull request less simpler than the other pull request. While #995 requires some more work (I will comment there soon on the results of my testing), it is the way to go, as it uses existing components.

QueryResultListResource::post allows plain parameters because it verifies you have permission to execute a query first. If you have a permission to run any query there is no risk of SQL injection (you can just run this query directly). Regardless we should consider moving to safe templating option, it just that we need to take into account that not all the data sources we support are SQL based...

[arikfr]

run_query might raise an exception, so better wrap it with a try/except.

[whummer]

done. changed in the updated PR

[whummer]

@arikfr Thanks for the update on this PR. Please see my changes corresponding to your comments.

[arikfr]

Merged. 🎉