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

Support server name signature for private plugins #36355

Closed
FStefanni opened this issue Jul 1, 2021 · 5 comments
Closed

Support server name signature for private plugins #36355

FStefanni opened this issue Jul 1, 2021 · 5 comments

Comments

@FStefanni
Copy link

Hi.

What would you like to be added:

It would be nice to be able to sign a private plugin once, for a group of grafana instances, related to some server(s) names.
At the moment it is required to add an explicit --rootUrls for each installation, which is not suitable in case of many grafana installations. So the suggestion is:

  • To allow a mismatch of root_url configuration and signature, as long as the signature is the domain. For example, signing for www.myserver.com should allow enabling the plugin in www.myserver.com/grafana1 and www.myserver.com/other/grafana2
  • To allow wildcard sub domains, *.myserver.com: to enable the plugin for each instance of grafana running on any matching sub-domain (e.g. grafana.myserver.com and support.me.myserver.com)

It should suffice to allow to pass --rootUrls www.myserver.com or --rootUrls *.myserver.com to enable the suggested signatures.

Why is this needed:

It is required in case of many grafana instances. In my case, we have in production more than 40 grafana instances, on 3 different servers. At the moment, we should sign our private plugin for each single grafana instance, which is not feasible. moreover, we should re-sign it for any new installation (again, it is a huge overhead).

Regards.

@marefr marefr added this to Todo in Plugins Platform (DEPRECATED) via automation Jul 5, 2021
@marefr marefr added this to Inbox in Backend Platform Backlog via automation Jul 5, 2021
@marefr marefr added area/plugins needs investigation for unconfirmed bugs. use type/bug for confirmed bugs, even if they "need" more investigating labels Jul 5, 2021
@wbrowne
Copy link
Member

wbrowne commented Jul 5, 2021

Hi @FStefanni - thanks for the contribution.

It's a great idea - one we have actually been speaking about recently and are planning to address it soon, starting with a design doc. The examples you provided I would think cover a high percentage of use cases, so that might likely be the first step, but still TBD.

@wbrowne wbrowne removed this from Inbox in Backend Platform Backlog Jul 5, 2021
@wbrowne wbrowne added this to Todo in Plugins Platform (DEPRECATED) via automation Jul 5, 2021
@wbrowne wbrowne added type/feature-request and removed needs investigation for unconfirmed bugs. use type/bug for confirmed bugs, even if they "need" more investigating labels Jul 5, 2021
@FStefanni
Copy link
Author

Hi,

great :) I'll wait for this feature in the next releases then.

Regards.

@wz2b
Copy link

wz2b commented Aug 14, 2021

Please see #36228 (comment)
#36228

@fatbasstard
Copy link

fatbasstard commented Aug 24, 2021

Hi!

Really like this idea (well, actually we need this). We build our Grafana instance with custom (in-house) plugins once and deploy it to different sites, all running in different subdomains: grafana.test1.example.com, grafana.test2.example.com, grafana.test3.example.com etc.

The amount of sites is unknown when building the image (and thus when signing the plugin) so some sort of wildcard support would help us out in this scenario.

@tolzhabayev
Copy link
Contributor

Closing as supported but on per-request basis #50652 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

6 participants