Ensure configured token is fetched during perms check

[mahendrapaipuri]

• Seems like auto provisioning does not work in multi org settings. A workaround is to turn off externalServiceAccounts feature flag and manually provision the plugin with a service account in each Org.

• This commit fixes on how we fetch the token between automatically provisioned and manually provided ones during permission checks.

Closes #48

[Davidkramer1999]

I think this will still not solve the issue. Because now, if you create a second organization and add a service account token, that token will only be permanent. That means when you switch back to the first organization (Main.org), the token from the previous organization will still be in the backend context. So, to make Main.org work, you are going to need another service account. This means you will always need to create a service account when switching between organizations.

As we discussed in previous issues, I would leave externalServiceAccounts turned on. So if you are in Main.org, you will always have the token to fall back on. The biggest problem is that you don’t know which dashboard is in which organization because you can easily write in the backend to support multiple organization tokens. Then, if you knew which dashboard is in which organization, you could just take the corresponding organization’s token.

This explanation highlights the need for a robust backend system capable of dynamically handling access tokens per organization and potentially tracking which dashboard belongs to which organization to manage access appropriately. If the system requires users to switch between multiple organizations frequently, consider implementing a more dynamic token management system or session-based handling where each session retains its organization-specific configurations and tokens.

We can maybe connect on linkedin and I can share my idea how to solve this...

[mahendrapaipuri]

Thanks @Davidkramer1999 for the detailed explanation. Here are some of my thoughts:

I think this will still not solve the issue. Because now, if you create a second organization and add a service account token, that token will only be permanent. That means when you switch back to the first organization (Main.org), the token from the previous organization will still be in the backend context. So, to make Main.org work, you are going to need another service account. This means you will always need to create a service account when switching between organizations.

In my tests, backend using correct token when I switch Orgs. My tests are as follows:

• Create a second Org.
• Create a user that has Viewer role on two Org.
• Login as user and attempt to create a report from Main Org. (report generated without any issues)
• Within the same browser session, switch to other Org. and create a report (report generated as well)

I have logged the token values on the backend and I noticed that when I switch Org. the token is being swapped as well. However this is when I configure the tokens manually instead of using externalServiceAccounts. If the token is being sticky, this must be some sort of side-effect of using externalServiceAccounts which is indeed a bug in Grafana as confirmed in this issue. So, the workaround for the current plugin is to manually configure the service tokens instead of using externalServiceAccounts.

Can you test the current patch with your deployment by disabling externalServiceAccounts and manually configuring service tokens? It should work and if not, it would be very helpful for me if you can provide a reproducer.

This explanation highlights the need for a robust backend system capable of dynamically handling access tokens per organization and potentially tracking which dashboard belongs to which organization to manage access appropriately. If the system requires users to switch between multiple organizations frequently, consider implementing a more dynamic token management system or session-based handling where each session retains its organization-specific configurations and tokens.

This must be fixed on Grafana side instead of current plugin. I mean the problem exists for any plugin that uses externalServiceAccounts on multiple Org setting. If you have ideas on how to fix it, I would suggest you to check out this issue and try to propose a fix on upstream.