Add Umami tracking to website head (HAN-609) #30

2026-10-13T11:03:58Z

multica-agent commented

2026-10-13 11:03:58 +00:00

Adds the two Umami snippets (script.js and recorder.js) to the <head> of the public website page web/api/static/index.html.

Closes HAN-609

🤖 Generated with Claude Code

Adds the two Umami snippets (`script.js` and `recorder.js`) to the `<head>` of the public website page `web/api/static/index.html`. Closes HAN-609 🤖 Generated with [Claude Code](https://claude.com/claude-code)

multica-agent added 1 commit 2026-10-13 11:04:01 +00:00

Add Umami tracking snippets to website head

CI / test (pull_request) Failing after 4s

Details

CI / docker (pull_request) Skipped

Details

51089fcd40

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

aibot reviewed

2026-10-13 11:05:07 +00:00

aibot left a comment

🤖 AI Code Review

Code Review: Add Umami tracking to website head (HAN-609)

1. Blocking issues

None. The change is straightforward and syntactically correct.

2. Non-blocking suggestions

Potential double-tracking: Both script.js and recorder.js carry the same data-website-id. In Umami, script.js handles pageview tracking while recorder.js handles session recording. If the version of Umami deployed also emits pageview events from recorder.js, you may see inflated pageview counts. Verify against your Umami version that recorder.js does not independently fire pageview events when data-website-id is present.
No Subresource Integrity (SRI): The scripts are loaded from an external origin without integrity or crossorigin attributes. If the Umami instance is ever compromised, arbitrary JS would execute in the origin context of ExploreDNS. Since this is a self-hosted instance the risk is lower, but adding SRI hashes (if your Umami version supports them) would be a defense-in-depth improvement.
CSP compatibility: If the server sets a Content-Security-Policy header (not visible in this diff), the script-src directive must allow https://umami.hansenits.com.au. Worth confirming the CSP header includes this origin, or the scripts will be silently blocked.
Privacy/consent: Adding tracking to a public page without a consent mechanism or privacy notice may have GDPR/privacy-law implications depending on your audience. This is a product/legal decision rather than a code issue, but worth flagging.

3. Tests

No tests are needed for this change — it's a static HTML addition with no logic. If existing tests in web/api/handler_test.go assert on the HTML structure or content, they should still pass since the additions are purely additive within <head>.

4. Overall assessment

Approve with minor considerations. The defer attribute is correctly used (non-blocking, preserves execution order), the URLs use HTTPS, and the change is minimal and focused. The main things to verify before or shortly after merge are the double-tracking behavior and CSP compatibility noted above.

Automated review by AI Git Bot

## 🤖 AI Code Review ## Code Review: Add Umami tracking to website head (HAN-609) ### 1. Blocking issues None. The change is straightforward and syntactically correct. ### 2. Non-blocking suggestions - **Potential double-tracking**: Both `script.js` and `recorder.js` carry the same `data-website-id`. In Umami, `script.js` handles pageview tracking while `recorder.js` handles session recording. If the version of Umami deployed also emits pageview events from `recorder.js`, you may see inflated pageview counts. Verify against your Umami version that `recorder.js` does not independently fire pageview events when `data-website-id` is present. - **No Subresource Integrity (SRI)**: The scripts are loaded from an external origin without `integrity` or `crossorigin` attributes. If the Umami instance is ever compromised, arbitrary JS would execute in the origin context of ExploreDNS. Since this is a self-hosted instance the risk is lower, but adding SRI hashes (if your Umami version supports them) would be a defense-in-depth improvement. - **CSP compatibility**: If the server sets a `Content-Security-Policy` header (not visible in this diff), the `script-src` directive must allow `https://umami.hansenits.com.au`. Worth confirming the CSP header includes this origin, or the scripts will be silently blocked. - **Privacy/consent**: Adding tracking to a public page without a consent mechanism or privacy notice may have GDPR/privacy-law implications depending on your audience. This is a product/legal decision rather than a code issue, but worth flagging. ### 3. Tests No tests are needed for this change — it's a static HTML addition with no logic. If existing tests in `web/api/handler_test.go` assert on the HTML structure or content, they should still pass since the additions are purely additive within `<head>`. ### 4. Overall assessment **Approve with minor considerations.** The `defer` attribute is correctly used (non-blocking, preserves execution order), the URLs use HTTPS, and the change is minimal and focused. The main things to verify before or shortly after merge are the double-tracking behavior and CSP compatibility noted above. --- *Automated review by AI Git Bot*

gary merged commit ee33a55d42 into main

2026-10-13 11:15:33 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: HansenITSolutions/ExploreDNS#30