Closed Bug 1425156 Opened 3 years ago Closed 3 years ago

regression: HTTP Basic Auth dialog won't appear


(Core :: Networking: HTTP, defect)

Not set



Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- fixed
firefox59 --- fixed


(Reporter: jan, Assigned: dragana)



(Keywords: nightly-community, regression)


(1 file, 1 obsolete file)

It's a bad build if you don't get asked for username + password and instantly see the error page.

If I directly open I could press OK.

But I have a problem if I want to access by awesomebar suggestion where I would normally get shown a pre-filled dialog and could just press Enter.

mozregression --good 2017-12-10 --bad 2017-12-13 --pref startup.homepage_welcome_url:""
> 5:01.19 INFO: Last good revision: 0285ac1b3755313f0b899708fe840f59717cb999
> 5:01.19 INFO: First bad revision: 09bf615d77d23dcac7c29f9faf696b94660eb7b7
> 5:01.19 INFO: Pushlog:

> c31b663b4dd2	Dragana Damjanovic — Bug 1409449 - Do not show auth-dialog for triggeringPrincipal==SystemPrincipal. r=ckerschb r=valentin r=francois

(I'm unable to block bug 1409449. editbugs permissions are not enough^^)

Personally I could live with this, but it's confusing.
Could you please CC me in bug 1409449? (I wasn't fast enough.) Thank you!
Flags: needinfo?(dd.mozilla)
This problem also occurs when pasting into the locationbar of a fresh profile and pressing Enter.
(Accessing would work to get a dialog, but a very bad advice.)

I like using HTTP Basic Auth to protect PowerAdmin/PHPMyAdmin and - what everyone should do - to protect WordPress installers:

(In general I like the idea to restrict basic auth to manual first-party requests (network.auth.subresource-http-auth-allow;0) in form of https://user:pw@host/.)
Even if a security issue would be the reason for this I couldn't imagine that you could ship such a behavior to ESR users.
An exception for accessing via bookmark or awesomebar would be useful.
I think I have a bug in my patch... I will fix it.
Assignee: nobody → dd.mozilla
Flags: needinfo?(dd.mozilla)
Thanks for reporting it so quickly, the patch just landed.
Attached patch bug_1425156.patch (obsolete) — Splinter Review
Attachment #8936781 - Flags: review?(ckerschb)
I forgot to remove my debuging fprintf-s.
Attachment #8936781 - Attachment is obsolete: true
Attachment #8936781 - Flags: review?(ckerschb)
Attachment #8936782 - Flags: review?(ckerschb)
Duplicate of this bug: 1425241
(In reply to Dragana Damjanovic [:dragana] from comment #2)
> I think I have a bug in my patch... I will fix it.

Can you explain what the bug in your code was semantically?
Flags: needinfo?(dd.mozilla)
Comment on attachment 8936782 [details] [diff] [review]

Review of attachment 8936782 [details] [diff] [review]:

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)
> (In reply to Dragana Damjanovic [:dragana] from comment #2)
> > I think I have a bug in my patch... I will fix it.
> Can you explain what the bug in your code was semantically?

Oh, I see, because top-level loads also use the SystemPrincipal as the triggeringPrincipal. I guess that makes sense.
Attachment #8936782 - Flags: review?(ckerschb) → review+
Pushed by
Fix bug in the http-auth dialog blocking. r=ckerschb
Flags: needinfo?(dd.mozilla)
Duplicate of this bug: 1425386
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Duplicate of this bug: 1425307
Verified fixed in Nightly 59 x64 20171215100105 de_DE @ Debian Testing (KDE). Thank you!

Now I will be asked for HTTP Basic Auth credentials when:
* pasting into the locationbar
* opening a bookmark
* opening a bookmark in the sidebar
* loading it as home page
Has Regression Range: --- → yes
Has STR: --- → yes
You need to log in before you can comment on or make changes to this bug.