Closed Bug 1653799 Opened 4 years ago Closed 4 years ago

DNS-over-HTTPS with authorization in URL no longer works

Categories

(Core :: Networking: DNS, defect, P3)

78 Branch
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mdavids, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

Steps to reproduce:

In 'network.trr.resolvers' I have this entry:

{"name":"AnyDoH SIDN Labs","url":"https://doh:BeGentle@anydoh.sidnlabs.nl/dns-query"}

This used to work. It worked also, when entered as 'Custom' URL in the 'Enable DNS over HTTPS' settings.

Actual results:

This way of using basic authorization no longer seems to work. I don't know in which version this behavior changed.

It still works with the 'network.trr.credentials' option ('Basic ZG9oOkJlR2VudGxl') in the advanced configuration, but I that is a lot harder to explain to my users.

Expected results:

https://doh:BeGentle@anydoh.sidnlabs.nl/dns-query used to work fine.

The DoH server requires authorization, this is intentional.

I wonder why it not longer works? Bug or feature (if so, why?)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Networking: DNS
Product: Firefox → Core
Flags: needinfo?(valentin.gosu)

This was never a supported way of passing credentials to the server.

It's unclear to me when this changed. @reporter, if you want to use mozregression to find when the problem started happening, it might be an easy fix.

With that said, I still don't think we want to support this as a way of adding authorization to DoH requests.

Blocks: doh
Severity: -- → S4
Flags: needinfo?(valentin.gosu)
Priority: -- → P3
Whiteboard: [necko-triaged]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

With that said, I still don't think we want to support this as a way of adding authorization to DoH requests.

Which, after second thoughts, I can imagine. I wasn't aware, but apparently this method was deprecated some time ago.

RFC3986, par. 3.2.1:
"Use of the format "user:password" in the userinfo field is deprecated."

I propose to close this ticket.

One more comment or rather a feature request;

It would be great if 'network.trr.resolvers' would get some sort of functionality, so that basic authorization can be configured in the json.

(In reply to mdavids from comment #3)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)
RFC3986, par. 3.2.1:
"Use of the format "user:password" in the userinfo field is deprecated."

I propose to close this ticket.

Thanks!

(In reply to mdavids from comment #4)

One more comment or rather a feature request;

It would be great if 'network.trr.resolvers' would get some sort of functionality, so that basic authorization can be configured in the json.

That pref is likely to see some changes in the near future, and is meant for UI purposes only.
I suspect it will be completely removed in net next few releases. I guess the proper way to do this would be a web extension once bug 1455425 lands.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.