Fenix: Firefox's Password Manager should work with HTTP authentication dialog

[yookoala]

Why/User Benefit/User Problem

It works on Firefox desktop and the Fennec. And it is kind of expected by users.

What/Requirements

Password Manager should work to remember HTTP authentication username / password just as it does for normal HTML login forms.

Acceptance Criteria (how do I know when I’m done?)

1. If a password of the HTTP authentication site is in the Password Manager, Fenix should display the suggested username and password on the popup login dialog.
2. If a password of the HTTP authentication site is NOT in the Password Manager, Fenix should wait until user entry then ask if she / he wants to store the login information to the Password Manager.

[yookoala]

A duplication of #4992. Close now.

[ekager]

I'm reopening this because it is about the internal password manager working with HTTP Authentication Dialogs and different than #4992

[TroelsS]

More info on this bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=993902

[TroelsS]

I do not think it is a "feature request" but rather a bug.

This worked fine in Firefox 68.0.1.

[fichtennadel]

see also https://github.com/mozilla-mobile/fenix/issues/9257

[yookoala]

Still doesn't work when it rolled out 😟

[TroelsS]

@ekager Shouldn't this be labeled as a bug?

[mpopp75]

This clearly is a bug and should be given higher priority.

[Antagony1060]

Why is this still flagged as a ‘feature request’? It is clearly a bug as the behaviour has regressed between versions.

This is a real pain for me as I use HTTP authentication extensively for testing and I don't want the hassle of having to fire up my separate password manager every time I want to check them via a mobile device.

[Dunexus]

Fenix is a entire rewrite of the browser around GeckoView.
As this feature has not been implemented in Fenix, it is a feature request (code that need to be written) and not a regression (code that worked and doesn't anymore).
The labels are from a developer's point of view to help them knowing where to look. This labeling choice is not used to deny the fact that this feature was present in Fennec (old-firefox) and has not been ported yet.

[WeirdConstructor]

From a user perspective this is a regression, as I just used to use Firefox on my mobile and from one day to the next it stopped working. Wish I could go back to the older Firefox version easily. As developer I understand that this is a feature "request" in case of a rewrite. As user I don't understand why a rewrite was necessary in the first place. And it breaks something I use on a daily basis. So I might have to go back to chrome for now.

[Antagony1060]

From a user perspective this is a regression, as I just used to use Firefox on my mobile and from one day to the next it stopped working.

Quite so @WeirdConstructor. The obvious concern for those of us objecting to the labelling/handling of this issue is that as a ‘feature request’ it will no doubt have a lower priority and therefore either take a long time to get fixed or may be ignored altogether. The very fact it still has no assignee fully seven months after it was opened would seem to vindicate that fear.

[aslmx]

This is still the case in recent Firefox builds.
It stopped working a few months ago, all of a sudden.

I wish this could be given the appropriate BUG label (or regression, as it has been pointed out often enough that this has worked just fine before) and priority.

It is utterly annoying.

[yookoala]

This is still the case in recent Firefox builds.
It stopped working a few months ago, all of a sudden.

I wish this could be given the appropriate BUG label (or regression, as it has been pointed out often enough that this has worked just fine before) and priority.

It is utterly annoying.

@aslmx

On July this year, the official release of "Firefox for Android" has switched from the old Fennec to a completely rewritten one, codename Fenix. Since this is a complete rewrite, the development team considers this previously Fennec-supported feature as a "new feature" in Fenix.

This is a bit ridiculous in users' perspective, but this is why this issue is not labelled a "bug".

[gusowski1]

But from an user perspective it is a bug and a reason to switch the browser
to get things working as expected.
I switched my primary mobile browser because of this reason weeks ago and
up to now i didn't switched back cause of several things not working
anymore.

I understand the behavior from a developer perspective - but from the
userpoint it is a nogo.
But it is a good way to lose more and more users.
But probably mozilla's user base has grown in sum within the last month
more as the lose of old fennec users cause of the switch from fennec to
fenix.

Am Mi., 7. Okt. 2020 um 14:50 Uhr schrieb Koala Yeung <
[email protected]>:

This is still the case in recent Firefox builds.
It stopped working a few months ago, all of a sudden.

I wish this could be given the appropriate BUG label (or regression, as it
has been pointed out often enough that this has worked just fine before)
and priority.

It is utterly annoying.

On July this year, the official release of "Firefox for Android" has
switched from the old Fennec https://wiki.mozilla.org/Mobile/Fennec to
a completely rewritten one, codename Fenix
https://github.com/mozilla-mobile/fenix. Since this is a complete
rewrite, the development team considers this previously Fennec-supported
feature as a "new feature" in Fenix.

This is a bit ridiculous in users' perspective, but this is why this issue
is not labelled a "bug".

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mozilla-mobile/fenix/issues/8642#issuecomment-704912963,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABOI3SGRYRF5VW2NCAJZEUTSJRPZBANCNFSM4KZGNA4A
.

[yookoala]

@gusowski1: No objection here. I think this is a bug / regression for me.

[Hubfront]

It's a bug, if the internal password manager can't handle basic authentification.

I guess, the reason for lazy developers to mark bugs as low priority "feature request" is, to have no pressure to touch or fix it.

Weird enough, until august 2020, it wasnt possible with fennec/fenix to even login into websites using the internal password manager. Although also clearly a bug, this was marked too as a feature request and took a year, until someone did bother to fix it, see #5551. How should firefox catch up with chrome, regarding usage share, if basic functionality isnt working for years?

[riksoft]

I confirm this huge bug is still in any firefox for Android available, even on the nightly.
This bug forces the user to retype user/pass every time.

Apparently there is also another bug
that prevents the workaround of passing user/password via url in the form user:pass@host that is a standard working on firefox desktop or any other browser mobile.

[Hubfront]

@riksoft Thats right. Firefox devs need to know, if they bother at all: it's not possible to copy the login credentials from the login credential page of fenix, because the login prompt will be gone already if you got back to the basic auth page. Simply reloading wont help either, because fenix wont bring the prompt back again, until you close the browser entirely with all opened tabs and sessions, and till you open the basic auth page again to insert the login credentials. But then you have only a copy of one of the two credentials: user or pass. If you choose to copy the password, what most of us will probably do, because the pass should be not easy to remember, you need to remember the username from the brain in order to fill it in the login prompt, paste the passwort to get finally logged. If a basic functionality is not working, it's a bug, not a feature request.

Maybe developement thinks, that we expect too much and that we should be thankful, that the internal passwort manager of fenix is able to fill in the appropriate login credentials when other authentification methods are used, at least after one year of "feature request" it was fixed in August 2020 ... well, if the mozialla team really wants firefox to catch up with chrome, they should probably fix at least the important bugs earlier, that prevent basic functionality, like log in in a website with user/pass , than they did in the past.

[Hubfront]

No one assigned after 9 months. Same is the case for the bug that addresses autofill of http auth dialog by 3rd party password manager.

Thats how you build non-competitive software.

[WeirdConstructor]

I am kind of relieved that I am not the only one relying on basic auth. And I also tried http://user:pass@domain/... - Chrome handles all this a little bit better.

I don't believe there is any malicious intend with the priority of this bug or missing feature.
Developers are usually trying their best, but are all bound to the resources and time that are allocated for them to work on issues/tasks. For some that is time they are paid to work on it, and for some it's time they are willing to invest without any compensation.

[ekager]

@Hubfront this is a warning that your behavior here is not acceptable. Please familiarize yourself with the CPG if you would like to interact with the team in this repo.

I have filed a Bugzilla ticket to discuss options here if you would like to follow along.
https://bugzilla.mozilla.org/show_bug.cgi?id=1676216

@riksoft Please open other bugs in new tickets, I'm not sure I understand your comment above about pasting

[Hubfront]

Its not my intent to get on someones nerves. I wish to fenix to get a better browser. It gets on my nerves, if i cant log in.

[ekager]

And I hear you that it gets on your nerves, but it is never helpful or acceptable to use language like "lazy developers" and "Thats how you build non-competitive software".

We have a very small team and almost 3k open issues. I'm sure everyone thinks the issue that bothers them the most is the most important.

[Hubfront]

I use firefox since some time and trust the team and their integrity more than the ones of other browser companies. I appreciate your work.

[riksoft]

@ekager "I'm not sure I understand your comment above about pasting"
I said "passing". To work around this problem I tried an intermediate page as a redirect to the target auth page, and this intermediate page was passing (get instead of post) a url in the form of user:pass@host. Unfortunately that doesn't work either (despite the desktop version of Firefox, and any other mobile browser work ok both with basich auth and this kind of URL).

I can't wait till this bug will be eventually solved, so I've though another way to work around this problem and I've found one perfect for my case. Hope this could be of use to others: I've "whitelisted" the LAN IPs in the same .htaccess used for the basic auth, so I can skip the authentication altogether when I'm accessing the page from the LAN or via SSH from remote.

AuthType Basic
AuthName "Secure Area"
AuthUserFile /xxxxx/xxxx/.htpasswd
Require valid-user
Require ip 192.168.0

That's not OK for any situations (e.g. not for a website accessed directly via http) but for local servers or http via SSH can do the job.

[aslmx]

I've "whitelisted" the LAN IPs in the same .htaccess used for the basic auth, so I can skip the authentication altogether when I'm accessing the page from the LAN or via SSH from remote.

I am doing exactly this for many years now, so that i don't have to fiddle around when i'm at home (or at work, where i SSH tunnel into my home network anyway).

However, this does not help in all cases. E.g. sometimes the WiFi seems active, but still Firefox (Android) asks me for basic auth. The connection seems to be stuck on mobile data then. This might be a problem of my smartphone, but anyways... This is just a workaround no solution.

I'm almost thinking about using client side certs to protect my selfhosted services. But i wouldn't really expect this to be working flawlessly when basic auth credentials can neither be stored nor be passed via URI...

[Hubfront]

@riksoft tx for sharing your workaround with us. You mentioned also, that any other mobile browser can both handle basic auth and passing the credentials via url like user:pass@host. fenix should be able to handle passing the credentials via url for basic auth too, as its a commonly used method of http 1.1 protocol. For the average user both methods have to work to make him happy.

For a student trying to access an restricted document on the server of his university, its frustrating to have all these credentials in the firefox database but they are useless, because the internal passwort manager cant use them when basic auth is used. In order to keep firefox for Android competitive and attractive having autofilling and storing credentials working is essential for user experience.

See also https://tools.ietf.org/html/rfc7235

[riksoft]

@aslmx @Hubfront
No doubt that mine is just a desperate workaround for personal stuff: I can't wait months or years for the real solution. However
Firefox mobile should surely manage standard protocols like basic auth or the url user:pass@host.

[aslmx]

Almost another 8 weeks passed.
I'm away from my LAN over christmas and everytime i access webpages hosted at home, I hit the .htaccess basic auth. I'm seriously annoyed.

If we can't get a date for the fix, can we get a date when this will be decided?

[Hubfront]

Almost another 8 weeks passed.
I'm away from my LAN over christmas and everytime i access webpages hosted at home, I hit the .htaccess basic auth. I'm seriously annoyed.

If we can't get a date for the fix, can we get a date when this will be decided?

Merry christmas to you. I would expect it to be fixed in Q1, thats what Eugen Sawin said. He works since 7 years for Mozilla and seems to have some influence in the developent team.. If we would see some progress in January on this would be gladly appreciated.