Mark ingress proxy as trusted in Z-Wave JS app

[AlCalzone]

Fixes the issues reported in zwave-js/zwave-js-ui#4535

Summary by CodeRabbit

• Bug Fixes
  • Fixed a validation error appearing in Z-Wave JS UI logs caused by improper proxy configuration handling.
  • Enhanced application compatibility with proxy layers and ingress endpoints, ensuring proper request processing and improved system stability.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 98ce42ca-c0db-4d14-897d-67283fbaefc9

📥 Commits

Reviewing files that changed from the base of the PR and between ad8a4b3 and 09f3b83.

📒 Files selected for processing (3)

• zwave_js/CHANGELOG.md
• zwave_js/config.yaml
• zwave_js/rootfs/etc/services.d/zwave_js/run

---

📝 Walkthrough

Walkthrough

A patch release (1.3.1) that updates the addon manifest version and configures the Z-Wave JS UI service to trust proxy connections by setting the TRUST_PROXY environment variable, with corresponding changelog documentation.

Changes

Cohort / File(s)	Summary
Patch Release 1.3.1 - Proxy Configuration zwave_js/CHANGELOG.md, zwave_js/config.yaml, zwave_js/rootfs/etc/services.d/zwave_js/run	Version bump to 1.3.1, changelog entry documenting proxy validation error fix, and service script now exports TRUST_PROXY=1 before starting zwave-js-ui to enable proxy trust configuration.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately summarizes the main change: marking the ingress proxy as trusted in the Z-Wave JS app by setting TRUST_PROXY=1.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR updates the Z-Wave JS add-on to trust the Home Assistant ingress proxy when running Z-Wave JS UI, addressing validation errors in logs related to proxy configuration.

Changes:

• Export TRUST_PROXY=1 in the add-on service run script so Z-Wave JS UI treats the ingress proxy as trusted.
• Bump add-on version from 1.3.0 to 1.3.1.
• Add a 1.3.1 changelog entry describing the proxy-related fix.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
zwave_js/rootfs/etc/services.d/zwave_js/run	Exports TRUST_PROXY=1 before launching zwave-js-ui.
zwave_js/config.yaml	Version bump to 1.3.1.
zwave_js/CHANGELOG.md	Adds release note for 1.3.1 describing the proxy validation log fix.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AlCalzone]

@agners I figure it would be slightly more correct to pass the actual ingress proxy IP - any clue how I can determine that programmatically?

[agners]

@agners I figure it would be slightly more correct to pass the actual ingress proxy IP - any clue how I can determine that programmatically?

Sorry for the late reply.

Best practice is to not use the same port to expose the web interface optionally outside (ports key) and ingress. Currently that is the case, the "Z-Wave JS UI web port" 8091 is also used for ingress. Detecting ingress based on source IP works in theory (source IP would be whatever supervisor resolves to), but it is not ideal as source IP could potentially be spoofed and makes your code messier than it needs to be.

Instead, set ingress_port to 0, which means Supervisor will assign a ingress port on startup. You can then read the dynamically assign port using $(bashio::addon.ingress_port). Then create a separate server. For this server you can assume any connection to be pre-authenticated by Supervisor/Home Assistant Core. You can also read the headers X-Remote-User-Id, X-Remote-User-Name, and X-Remote-User-Display-Name (see also Authenticating a user when using ingress) to learn what user is accessing Z-Wave JS via Ingress. Today only admin users have access to Ingress. I probably need to expand that section a bit.

Note that with ESPHome and Music Assistant thins are a bit more complicated since they operate with host_network: true. In that mode, no "truly" internal IP is available. The hassio gateway IP used to be open to the public and only recently got protected. But this did not apply for regular apps like Z-Wave JS.

[agners]

Btw, there is also the idea to support ingress via Unix domain socket which is by nature only available local and would secure access quite nicely.

[AlCalzone]

I've started implementing the 2nd server approach in Z-Wave JS UI. I'll go with that.
Will mark this as draft for now, so I don't lose track of the explanation above.