Fix reverse proxying in Settings

[gunjambi]

getLoc has an off-by-one where reverse proxy path gets parsed wrong if it's routed on the top-level path.

I have WLED in domain.com/wled/. On settings page we compute:

let path = l.pathname; // `/wled/settings`
let paths = path.slice(1,path.endsWith('/')?-1:undefined).split("/");   // [ "wled", "settings" ]
if (paths.length > 1) paths.pop(); // [ "wled" ]
if (paths.length > 0 && paths[paths.length-1]=="settings") paths.pop(); // No change

// paths.length == 1 so this isn't taken
if (paths.length > 0) {
	locproto = l.protocol;
	loc = true;
	locip = l.hostname + (l.port ? ":" + l.port : "") + "/" + paths.join('/');
}

This then breaks the computation for the "s.js" path.

If I have WLED in domain.com/w/led/ the above paths.length > 0 is taken as expected and settings work.

This PR fixes the off-by-one

Summary by CodeRabbit

• Bug Fixes
  • Improved URL path handling for reverse-proxy configurations to enable localization settings to work with single-segment paths, in addition to the previously supported multi-segment paths.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The condition in getLoc() for populating localization data is adjusted from requiring more than one path segment to requiring at least one path segment, expanding when reverse-proxy localization logic triggers.

Changes

Cohort / File(s)	Summary
Localization Path Logic wled00/data/common.js	Modified getLoc() condition from paths.length > 1 to paths.length > 0, expanding when localization data (loc, locip, locproto) are populated for reverse-proxy configurations

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix reverse proxying in Settings' directly addresses the main change: fixing getLoc() logic for correct reverse-proxy path parsing in the Settings page.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8a2a705 and 23517ea.

📒 Files selected for processing (1)

• wled00/data/common.js

🧰 Additional context used

📓 Path-based instructions (2)

wled00/data/**/*.{htm,html,css,js}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use tabs for indentation in web files (.htm/.html/.css/.js) under wled00/data

Files:

• wled00/data/common.js

wled00/data/**

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

wled00/data/**: When modifying web UI files, run npm run build to regenerate embedded headers before any firmware build
For web UI changes, edit files only under wled00/data (not firmware or generated files)

Files:

• wled00/data/common.js

🧠 Learnings (1)

📓 Common learnings

Learnt from: blazoncek
Repo: wled/WLED PR: 5140
File: wled00/data/settings_time.htm:66-76
Timestamp: 2025-12-01T07:01:16.949Z
Learning: In WLED PR #5134, the fix for macros being initialized with the enable bit set only handles new configurations, not existing ones. If there is a bug in timer/macro handling code (e.g., in settings_time.htm), it must be fixed to work correctly for existing configurations as well.

🧬 Code graph analysis (1)

wled00/data/common.js (1)

wled00/data/index.js (1)

• paths (231-231)

🔇 Additional comments (1)

wled00/data/common.js (1)

106-127: LGTM! The reverse proxy detection logic is sound.

The getLoc() function correctly handles reverse proxy paths at various nesting levels. For top-level reverse proxy paths like /wled/settings, after line 119-120 processes the path segments, the remaining segment (e.g., ["wled"]) properly triggers the reverse proxy localization via the paths.length > 0 check on line 121. The logic doesn't introduce regressions for non-reverse-proxy scenarios where paths becomes empty. Indentation uses tabs as required by coding guidelines.

---

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

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

[softhack007]

@gunjambi did you test that it works as before when users don't use a reverse proxy?

[gunjambi]

Yes, I've tested Settings page works with the following urls:

• domain.com/wled/ (reverse proxy, one level)
• domain.com/w/led/ (reverse proxy, two levels deep)
• 1.2.3.4/ (IP address)
• wled-wled-b.lan (top level) (.lan is local area dns suffix)

[netmindz]

I hope that remote proxy is not being used to expose WLED to the public internet - that is a really bad idea. Frankly support use behind a proxy should never really have been added as it risks people thinking it's ok to expose online

[gunjambi]

I use a reverse proxy to expose WLED over internet over TLS. I use an authentication proxy to limit access to only myself. Access over internet is convenient so I can control my christmas lights. my wlan doesn't have a long range.

Can you expand what are your concerns why you think exposing the WLED over internet is a bad idea so we know we are talking of the same problem. I'm not trying to be sarcastic here. There are few concerns I can think of:

A) Unauthenticated access: since WLED doesn't support and doesn't intend to support authentication, having authentication could have configure hardware wrong and break it. Or flash it and take over and run malicious code.

B) Reverse proxying to non-top level path means the web applications are sharing cookies / resources with other apps under the same domain. This could cause issues if WLED used cookies?

---

For B) I don't see this is as a concern. WLED doesn't use cookies or any web permissions so it can't get mixed up here. And if you manually do upload html and js via /edit, yes, you can access the cookiejar of the domain. This would only be a vulnerability if some external party is hosting the WLED for you on a domain running some other web app. Not realistic, and even still it's not a WLED vulnerability.

For A). Yes, unauthenticated use is unsafe, but that's hardly a unique problem for WLED. For any service you expose to internet, you need ensure proper authorization. Rather than say this is too dangerous, maybe there should be a guide how to do it safely, i.e. add an authentication proxy. People are doing this already, so arguably the cat is out of the bag.

If we want some technical seatbelts, I guess we could check the IP for all incoming requests and opt-out reject all not in common local network IP address spaces (and captive portal). Additionally, we could check for X-ForwardedFor header to detect the presence of a proxy. I don't believe these would change anything however as users would simply turn the checks off.

[netmindz]

I am relieved to hear your proxy setup is adding an additional authentication layer, I fear many (most?) do not

While I hope that no users are port forwarding WLED, I'm sure there are instances of that, which is why we have restricted OTA to only be from the same subnet, however this protection is defeated by a proxy

[gunjambi]

Here's a doc PR which I hope alleviates these concerns. Specifically it:

• Avoids encouraging use of port forwading. Instead, we clearly say it is unsafe at any speed.
• Adds doc page describing access over internet via reverse proxy. Page clearly states HTTPS and access control are mandatory.

MoonModules/WLED-Docs#12