Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add full support for OBO user requests #533

Merged
merged 4 commits into from Jan 11, 2023
Merged

Conversation

aangelisc
Copy link
Contributor

This PR ensures that all requests make use of the user identity if the datasource is configured to do so.

grafana-plugin-sdk-go recently added the appropriate support for header forwarding allowing the X-ID-TOKEN header to be accessed in external plugins.

Fixes #509
Fixes grafana/grafana-plugin-sdk-go#579

@aangelisc aangelisc added enhancement New feature or request effort/small changelog PRs to include in the CHANGELOG labels Jan 9, 2023
@aangelisc aangelisc requested a review from a team as a code owner January 9, 2023 18:07
@aangelisc aangelisc self-assigned this Jan 9, 2023
@github-actions
Copy link

github-actions bot commented Jan 9, 2023

Backend code coverage report for PR #533

Plugin Main PR Difference
azuredx 33.3% 33.3% 0%

@github-actions
Copy link

github-actions bot commented Jan 9, 2023

Frontend code coverage report for PR #533
No changes

Copy link
Contributor

@kostrse kostrse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome that a recent version of Plugin SDK already supports headers for CheckHealth.

This fixes #509, but could we keep the grafana/grafana-plugin-sdk-go#579 open since that is a general feature request that would be good to consider by itself?

@@ -43,7 +43,7 @@ func (c *Client) TestRequest(ctx context.Context, datasourceSettings *models.Dat
}

// TODO: This is a workaround because Plugin SDK doesn't expose user context for CheckHealth
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TODO not needed anymore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Copy link
Contributor

@andresmgot andresmgot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job here 👍

One slighly weird thing is that if the user creating the data source is not logged with OAuth, the check fails with:

Screenshot from 2023-01-10 11-49-51

I am not sure what would be the best UX here for that situation, we could probably catch the error and show something like "Unable to check data source, the current user has not signed in with OAuth". WDYT?

@kostrse
Copy link
Contributor

kostrse commented Jan 10, 2023

One slighly weird thing is that if the user creating the data source is not logged with OAuth, the check fails with:

Screenshot from 2023-01-10 11-49-51

I am not sure what would be the best UX here for that situation, we could probably catch the error and show something like "Unable to check data source, the current user has not signed in with OAuth". WDYT?

This error can be due to other cause like not enabled auth token pass-thru.

Ideally user should not see this error at all.

I would add a task to intestigate how to show this type of authentication only if OAuth was used or to specifically check whether user was signed in using OAuth and show error message which explicitly tells that auth isn't possible becaue OAuth wasn't used.

Let's keep it to a separate task, this PR fixes check health.

Since it's experimental feature under a feature flag, it's OK if it fails when enabled for non OAuth. It's not enabled by defailt and users which enable it expected to understand scenario when it works.

@aangelisc
Copy link
Contributor Author

I am not sure what would be the best UX here for that situation, we could probably catch the error and show something like "Unable to check data source, the current user has not signed in with OAuth". WDYT?

My preference would be to actually prevent any requests made if a user signed in with the standard method (service account) attempts to make requests via an OAuth datasource. I think we should maybe implement a catch-all for this situation and return an error along the lines of Invalid credentials, attempting to use Service Account credentials with OBO authentication enabled.

@andresmgot
Copy link
Contributor

I would add a task to intestigate how to show this type of authentication only if OAuth was used or to specifically check whether user was signed in using OAuth and show error message which explicitly tells that auth isn't possible becaue OAuth wasn't used.

Let's keep it to a separate task, this PR fixes check health.

Sounds good to me

I am not sure what would be the best UX here for that situation, we could probably catch the error and show something like "Unable to check data source, the current user has not signed in with OAuth". WDYT?

My preference would be to actually prevent any requests made if a user signed in with the standard method (service account) attempts to make requests via an OAuth datasource. I think we should maybe implement a catch-all for this situation and return an error along the lines of Invalid credentials, attempting to use Service Account credentials with OBO authentication enabled.

Also agree, just remember to log the original error so we can debug in case we are masking an unexpected error

@aangelisc
Copy link
Contributor Author

Also agree, just remember to log the original error so we can debug in case we are masking an unexpected error

Great, in this case I'll merge this and open a separate issue as suggested by @kostrse with the above implementation as a solution 😊

@aangelisc aangelisc merged commit a620301 into main Jan 11, 2023
@aangelisc aangelisc deleted the support-check-health-obo branch January 11, 2023 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog PRs to include in the CHANGELOG effort/small enhancement New feature or request
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

IdToken as part of PluginContext.User All requests should use user identity auth if user identity configured
3 participants