Basic authentication with user/pwd provided in the URL is not working anymore since version 2.1.16.

[timovanroermund]

Basic authentication with user/pwd provided in the URL is not working anymore since version 2.1.16.

When using an URL like this -- http://user:password@127.0.0.1:8080/ -- the script /static/monitoring.js throws the following errors:

Polling metrics failed: TypeError: Window.fetch: /api/metrics is an url with embedded credentials.
Initial metrics load failed: TypeError: Window.fetch: /api/metrics is an url with embedded credentials.
Error: TypeError: Window.fetch: /api/metrics is an url with embedded credentials.

When providing the user/pwd manually (browser popup), rather than via the URL, it does work.

In previous versions, this worked fine.

Is this an intended change in behavior?

[jedisct1]

3d1a190 may fix it

[timovanroermund]

Thanks!

I'm keeping the comment in the original (deleted) bug report here for completeness:

Thanks for filing this. I checked the current code and the related discussion, and I think this is a real compatibility regression in the monitoring dashboard path, although not a failure in the Go basic-auth middleware itself.

The behavior changed in v2.1.16 because the dashboard was moved away from the old JSONP/script-tag metrics loading path. Commit 5dfd19d removed JSONP support from /api/metrics to fix an authenticated metrics exfiltration issue, and commit 412c5cb changed dnscrypt-proxy/static/js/monitoring.js to call fetch('/api/metrics', { credentials: 'same-origin', ... }). That is the current code at dnscrypt-proxy/static/js/monitoring.js:392-402, with the initial load at :405-416 and the polling fallback at :516-526.

When the page itself is opened as http://user:password@127.0.0.1:8080/, resolving the relative URL /api/metrics inherits that userinfo in the browser's URL resolution step. The Fetch API rejects request URLs containing embedded credentials before the request is sent, which matches the exact error you saw. Opening http://127.0.0.1:8080/ and entering the credentials in the browser prompt works because the document URL no longer contains embedded credentials, and the browser can still send the normal Basic Authorization header.

On the server side, the monitoring UI is still wired through basicAuthMiddleware: dnscrypt-proxy/monitoring_ui.go:223-239 registers /, /api/metrics, /api/ws, and the static JS under the same authenticated handler, and dnscrypt-proxy/monitoring_ui.go:1227-1246 validates r.BasicAuth(). The metrics endpoint itself now just serves JSON at dnscrypt-proxy/monitoring_ui.go:1073-1099. The example configuration only documents the configured monitoring username and password in dnscrypt-proxy/example-dnscrypt-proxy.toml:1013-1017; it does not say that credentials embedded in the URL are a supported access method.

There is already a follow-up Discussion for the same report at #3244, and an earlier related note in #3203 where the same embedded-credentials fetch error was identified. Given that this issue was already closed by the template bot, I would keep the technical follow-up in discussion #3244 rather than reopen this issue.

For now, the practical workaround is to open the dashboard without user:password@ in the URL and let the browser's Basic Auth prompt store/send the credentials. If maintainers want to preserve the old shortcut, the fix would probably need to avoid constructing Fetch requests from a document URL that contains userinfo, while still keeping the JSONP removal from v2.1.16 intact for security.

This is an automated reply by Swival (https://swival.dev/) using only open-source models, intended to help both the reporter and the maintainers move the issue forward.

[62f1346c-4576-42b3-afcb-23ef1820da34]

this only fixes the error message, embedded credentials no longer work, right?
(fine for me, it's deprecated by rfc3986)

[timovanroermund]

Credentials embedded in the URL work again after applying this fix. So it's not just hiding the warning.

And yes... using credentials in the URL is deprecated. But in some cases, it can be acceptable. Here, with dnscrypt-proxy, it can be an acceptable tradeoff between ease-of-use and (sufficient) security -- especially when used in conjunction with HTTPS, which protects the credentials in transit.