Navidrome widget fails with "Wrong username or password" when salt contains "+" (query params not URL-encoded)

[elazar]

Summary

The Navidrome widget builds its Subsonic API request by raw string interpolation without percent-encoding query parameters. If the Subsonic auth salt contains a +, Go's net/url decodes it as a space server-side, so the md5(password + salt) check never matches and every request returns Subsonic error 40 ("Wrong username or password") even with correct credentials.

Repro

With user demo, token = md5(password + salt), salt NbI+rOjamb59hn3r, against any Navidrome instance:

# Fails: error 40
curl 'https://navidrome.example/rest/ping?u=demo&t=<token>&s=NbI+rOjamb59hn3r&v=1.16.1&c=homepage&f=json'
# Succeeds: status ok — identical credentials, salt percent-encoded
curl 'https://navidrome.example/rest/ping?u=demo&t=<token>&s=NbI%2BrOjamb59hn3r&v=1.16.1&c=homepage&f=json'

The widget emits exactly the failing form: src/widgets/navidrome/widget.js defines "{url}/rest/{endpoint}?u={user}&t={token}&s={salt}&v=1.16.1&c=homepage&f=json", and formatApiCall (src/utils/proxy/api-helpers.js) substitutes values verbatim with no encoding before genericProxyHandler fetches it. This bites anyone generating salts with openssl rand -base64.

Expected: widget authenticates with any RFC 3986-safe salt.
Actual: error 40 unless the salt happens to contain no + (or other reserved characters).

Root cause & references

• Upstream confirmed client-side: Authentication fails when the salt for Subsonic API contains a plus character navidrome/navidrome#4767 (closed as not-a-bug — clients must percent-encode per RFC 3986; the Homepage widget is explicitly named as reproducible)
• Same bug class previously accepted and fixed: [Bug] qBittorrent widget fails to log in when the password contains special characters #1547 (qBittorrent passwords with special characters)

Suggested fix

Encode substituted query values — minimally for the Navidrome widget (e.g., a small proxy handler assembling the URL with URLSearchParams, consistent with existing per-widget proxy handlers), or centrally in the template substitution if feasible. Happy to submit a PR if maintainers agree on the approach.

[github-actions[bot]]

Dear homepage user, thanks for opening this discussion! Please ensure you add the output from the troubleshooting guide steps, the support template asks for those details because they usually make it possible to understand the problem without guessing. Please update the discussion with the relevant troubleshooting output, configuration, logs, and browser console details where applicable: https://gethomepage.dev/troubleshooting/. Thank you!