feat: add Grafana dashboard proxy app

Mark-van-der-Klaauw commented

2026-06-08 21:09:59 +02:00

Contributor

Adds the Grafana dashboards proxy. Following the same pattern as the existing nodered app.

The dashboard Live data and sensors is embedded in a Django page at /dashboard_intranet/grafana_live_data_and_sensors/

Access control: All authenticated members will be able to view the dashboards, and admins and members of the grafana admin group get a "Grafana editor" link in their trustees navigation menu

For now I haven't added any navigation links to the Grafana dashboards yet, so I can test them on production first before exposing them to members.

Adds the Grafana dashboards proxy. Following the same pattern as the existing nodered app. The dashboard Live data and sensors is embedded in a Django page at /dashboard_intranet/grafana_live_data_and_sensors/ Access control: All authenticated members will be able to view the dashboards, and admins and members of the grafana admin group get a "Grafana editor" link in their trustees navigation menu For now I haven't added any navigation links to the Grafana dashboards yet, so I can test them on production first before exposing them to members.

Mark-van-der-Klaauw added 1 commit

2026-06-08 21:10:00 +02:00

feat: add Grafana dashboard proxy app

Verify Pull Request / tests (pull_request) Successful in 2m29s

Details

f9355def89

Luke-Watts commented

2026-06-10 19:00:48 +02:00

Owner

@Mark-van-der-Klaauw can we use OIDC/IDP auth so we can allow members to log in using the same pattern we have for Forgejo, Nextcloud and the Wiki?

Mark-van-der-Klaauw commented

2026-06-14 14:42:06 +02:00

Author

Contributor

@Luke-Watts
Short answer: I propose we look into that after this PR, as a 'nice to have'.

For your information:
Note that this PR is the first step, getting the proxy working and verifying the production setup before exposing it to members. It is hard to test this completely on my local dev server, and in addition it will require a change in the Grafana settings grafana.ini file on production to make it work.

Note that the architecture here is that Grafana itself only serves requests that come from the server, it is not opened up to the internet directly. So from the outside, Grafana is only accessible through the Django proxy at /grafana/, for members that are logged in to the Django website. The website uses a similar construction already for Node-RED.

Grafana will allow anonymous local access to show the dashboards inside Django, and will allow editing to editors only after they log in to Grafana.

The idea is that we don't block regular members from viewing the dashboards, the regular members are only blocked from editing the dashboards. Regular members see only navigation links to dashboards that are relevant to them, and those links include ?kiosk in the URL so they don't see the Grafana specific sidebar menu and top bar menu.

So Django will show the dashboards to all regular members in kiosk mode. And the members who are either privileged users (trustees/admins) or part of the grafana admin group will additionally see a "Grafana editor" navigation link in the trustee menu, pointing to Grafana without kiosk mode, giving them access to the full Grafana interface through the same proxy.

However, the current architecture means that Grafana editors will still need to log in to Grafana separately to be able to edit. This is an extra step.

To log in to Grafana as an editor, they can use the Grafana credentials found on the landing page of the intranet site, in the passwords section. All editors share the same Grafana credentials.

I agree this architecture is not ideal, especially since some members of the grafana admin group may not be part of the privileged groups that have permission to see the administrator passwords on the landing page. For those members in particular, single sign-on would be nicer.

I consider single sign-on here a 'nice to have'. But as we are still figuring out Grafana and just starting to work with it, let's try it without first.

Note that after this PR, the dashboards will be essentially hidden from regular users, by design, just for now. There are no navigation links to the dashboards for regular members, so they would only be able to find them by typing the URL directly.

@Luke-Watts Short answer: I propose we look into that after this PR, as a 'nice to have'. For your information: Note that this PR is the first step, getting the proxy working and verifying the production setup before exposing it to members. It is hard to test this completely on my local dev server, and in addition it will require a change in the Grafana settings grafana.ini file on production to make it work. Note that the architecture here is that Grafana itself only serves requests that come from the server, it is not opened up to the internet directly. So from the outside, Grafana is only accessible through the Django proxy at /grafana/, for members that are logged in to the Django website. The website uses a similar construction already for Node-RED. Grafana will allow anonymous local access to show the dashboards inside Django, and will allow editing to editors only after they log in to Grafana. The idea is that we don't block regular members from viewing the dashboards, the regular members are only blocked from editing the dashboards. Regular members see only navigation links to dashboards that are relevant to them, and those links include ?kiosk in the URL so they don't see the Grafana specific sidebar menu and top bar menu. So Django will show the dashboards to all regular members in kiosk mode. And the members who are either privileged users (trustees/admins) or part of the grafana admin group will additionally see a "Grafana editor" navigation link in the trustee menu, pointing to Grafana without kiosk mode, giving them access to the full Grafana interface through the same proxy. However, the current architecture means that Grafana editors will still need to log in to Grafana separately to be able to edit. This is an extra step. To log in to Grafana as an editor, they can use the Grafana credentials found on the landing page of the intranet site, in the passwords section. All editors share the same Grafana credentials. I agree this architecture is not ideal, especially since some members of the grafana admin group may not be part of the privileged groups that have permission to see the administrator passwords on the landing page. For those members in particular, single sign-on would be nicer. I consider single sign-on here a 'nice to have'. But as we are still figuring out Grafana and just starting to work with it, let's try it without first. Note that after this PR, the dashboards will be essentially hidden from regular users, by design, just for now. There are no navigation links to the dashboards for regular members, so they would only be able to find them by typing the URL directly.

Mark-van-der-Klaauw force-pushed feat/grafana-dashboard-proxy from f9355def89

Verify Pull Request / tests (pull_request) Successful in 2m29s

Details

to 94cb864ada

Verify Pull Request / tests (pull_request) Successful in 1m44s

Details

2026-06-17 15:31:08 +02:00

Compare

Verify Pull Request / tests (pull_request) Successful in 1m44s

Required

Details

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u feat/grafana-dashboard-proxy:Mark-van-der-Klaauw-feat/grafana-dashboard-proxy

git switch Mark-van-der-Klaauw-feat/grafana-dashboard-proxy

Rows
Columns

feat: add Grafana dashboard proxy app #86

Checkout