Hi, I’ve been using the Infinity datasource plugin to access REST API data in custom Grafana panels without having to expose the API keys of the backend service. Unfortunately I see the only configurable methods are GET and POST, but the other methods our backend service uses (PUT, DEL and PATCH) are not exposed.
Also on a side note, when running a query with the method set as PATCH in the url_options field, the code basically does an if (PATH) else (GET), returning a status code of 200 if that GET endpoint exists.
I would expect at least an error code along the lines of method not supported.
@sowdenraymond so with POST, you can’t “manipulate” data? (Or with GET, even if against the grain, if you really want to). I think the opaquely transforming a PATCH or DEL request to a GET without any feedback and returning a 200 status_code is more of a bug than a feature request, but I will go through the repo and see if there is any interest in these features.
@solitcon I had looked at this plugin (although @sowdenraymond seems to think what it does is not a good idea). I might be mistaken, but the requests are directly sent from the browser, correct? The advantage of the infinity datasource is that authentication headers (for example) can be hidden in the datasource configuration, and the browser will never have access to API Keys etc, which gives me an additional level of control and data acess separation.
Would this be correct, or is there some way I can configure this in Business Forms?
i didn’t say it was not possible, i said grafana is meant for fetching data and displaying it, not manipulating data.
i didn’t say there is not a requirement for this sometimes as well, but you should try and maintain segregation of duties where possible.
update your data where you have all the business rules, access rules, data rules etc. in place, otherwise you now need to start building those layers into grafana…
@sowdenraymond There are and more people interesting in the manipulation data in Grafana. Based on the downloads statistics for Business Forms panel interest exploded in 2024.
@mikhailvolkov - there will always be a need for data editing, and your plugins are awesome!
i am still of the opinion however that segregation of duties should apply, and you should edit your data where it is meant to be edited, not directly in the db (unless there is no other option) or via an observability tool… neither of which respect your business rules, data validation rules, security and access rules, change control etc. unless you build those layers into the tool you use, and then you are replicating your business logic and creating silos. now when your business changes and you need to adapt your logic, now you have multiple places to go and update instead of just one…
the best approach I have found out to address these very important concerns is not using inline queries but using stored procedures.
grant execute on them to a permission group that includes the service account used on the query connection, lock down permissions on the stored procedure.
then it would make the CRUD implementation , implementer agnostic
create procedure useractivities_ip(
@userguid uid,
@actitivities varchar(max)
)
as
begin
insert into user_activities
yadi yada
end
go
grant exec on useractivities_ip to data_loaders
–data_loaders is a security group the grafana user/service user is added to. never grant permission to a user, rather to a group the user is added to.
