Forward grafana meta values to downstream API #1072
Conversation
…s to the 3rd party API endpoint (#1056)
yesoreyeram
force-pushed
the
grafana-headers-forwarding
branch
from
58a8f7a to
fb1799b
Compare
yesoreyeram
changed the title
yesoreyeram
changed the title
yesoreyeram
changed the title
yesoreyeram
changed the title
| if pCtx.DataSourceInstanceSettings != nil { | ||
| value = strings.ReplaceAll(value, "${__ds.uid}", pCtx.DataSourceInstanceSettings.UID) | ||
| value = strings.ReplaceAll(value, "${__ds.name}", pCtx.DataSourceInstanceSettings.Name) | ||
| value = strings.ReplaceAll(value, "${__ds.id}", fmt.Sprintf("%d", pCtx.DataSourceInstanceSettings.ID)) | ||
| } | ||
| if pCtx.User != nil { | ||
| value = strings.ReplaceAll(value, "${__user.login}", pCtx.User.Login) | ||
| value = strings.ReplaceAll(value, "${__user.email}", pCtx.User.Email) | ||
| value = strings.ReplaceAll(value, "${__user.name}", pCtx.User.Name) | ||
| } |
There was a problem hiding this comment.
Should we throw error in such nil cases to assist more to the users? or it would cause more inconvenience? ( If this used in the context of cron/anonymous jobs such as alert, public dashboard... then potentially the queries will silently fail there without much context but may succeed in the dashboards / explore page )
There was a problem hiding this comment.
I think throwing an error make sense. I was thinking about logging an error here but it may be better to throw and surface the error to the end user. Thinking out loud that would mean that the query would fail and not run because of this. right? So a user would have to create a separate ds with headers and without headers which is not ideal. How should we let the user know that these headers won't work in alert?
There was a problem hiding this comment.
yea. it is bit tricky. I prefer to go with current approach now and then later iterations, we can figure out if we can send warnings to the frontend in such cases.
|
@mahendrapaipuri - if u have more thoughts around this, suggest to respond here in the thread so that it will be useful for reviewers |
This PR will allow datasource authors to pass grafana meta data such as user id, datasource uid to the underlying API as query parameters / headers.
Any value set by the user in query will be overidden by the values from the data source settings.
Fixes #1073
Fixes #867
Fixes #457
Design decisions & FAQs
send_user_header? Answer: That setting is applicable for all the datasource instances. But in infinity, as said before not all the APIs will like additional headersHow to test this
Before changes
git checkout main && git pull && yarn && yarn build && mage -vdocker compose upOpen http://localhost:3000
add a new infinity datasource instance
in datasource custom http header add a new key
X-Grafana-Userwith value${__user.login}in datasource URL query parameter add a new key
X-Grafana-Datasource-UIDwith value${__ds.uid}Add
https://httpbin.orgto the allowed hostsSave and test the datasource
Create a query in explore with URL and backend parser option
Add
https://httpbin.org/getas URL and run the query. Inspect headers and args in the resultAfter changes
git checkout grafana-headers-forwarding && git pull && yarn && yarn build && mage -vdocker compose upOpen http://localhost:3000
add a new infinity datasource instance
in datasource custom http header add a new key
X-Grafana-Userwith value${__user.login}in datasource URL query parameter add a new key
X-Grafana-Datasource-UIDwith value${__ds.uid}Add
https://httpbin.orgto the allowed hostsSave and test the datasource
Create a query in explore with URL and backend parser option
Add
https://httpbin.org/getas URL and run the query. Inspect headers and args in the resultalso in query inspector