Closed
Bug 187720
Opened 22 years ago
Closed 18 years ago
Password auto-fill doesn't distinguish between HTTP authorization and HTML forms (only one keychain entry per site)
Categories
(Camino Graveyard :: OS Integration, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino1.5
People
(Reporter: michael, Assigned: stuart.morgan+bugzilla)
References
Details
(Keywords: fixed1.8.1.2)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+ I've seen this on a website that uses a forum system that has been made private with a standard web password (htaccess style). Basically the password to get into the private directory is taken and saved (after asking and the user saying yes). This is the standard htaccess style password. However the forum has a separate CGI based password system. And when you visit that page the wrong password is auto entered into the form fields. Reproducible: Always Steps to Reproduce: 1. Save a password from a htaccess stlye login system. 2. Use a cgi-based password form on the same site... Actual Results: The incorrect password is entered. Expected Results: I would expect that a user would never have the need to use the same password on a form based system that they used on a htaccess style system. I would expect that Chimera (or Mozilla if this isn't Chimera specific) would separate the two styles of password input and not group them together. If this is not possible then can the htaccess password sheet remember my "don't save" choice on a domain basis? Currently I have to select no each time I visit the site to work around the 'bug'.
The Web mail service at www.myrealbox.com uses the same login and password for HTTP (mail.myrealbox.com) and HTML-form-based access (www.myrealbox.com). There are certainly some sites where you would want one password for HTTP and a different password for HTML, and there are sites where you would want one password for one form and a different password for a different form. But there are also many sites where you want the same password across the domain, and the current behavior is good for these sites. Should this bug be WONTFIX?
Comment 2•22 years ago
|
||
C. there should at least be a way to separate the two, if you need that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 3•22 years ago
|
||
Well personally I doubt that using the same password for both is all that common really. Usually if you have to login via htaccess your already authorized and another password manually isn't needed. I'd suggest separating the two. Worst case scenario that way is that someone has to enter a password twice to get it both places. As it is now I can't use the feature on the site I'm using, and must manually unclick the "save password" box ever time I visit, quite annoying.
Comment 4•21 years ago
|
||
does safari do the right thing here?
Assignee: saari → pinkerton
Target Milestone: --- → Camino1.2
Reporter | ||
Comment 5•21 years ago
|
||
Yes Safari does do the correct thing.
Assignee | ||
Comment 6•20 years ago
|
||
Updating summary to distinguish from bug 178607 Was "Password auto-entered when not expected/desired"
Summary: Password auto-entered when not expected/desired → Password auto-fill doesn't distinguish between HTTP authorization and HTML forms
*** Bug 198162 has been marked as a duplicate of this bug. ***
The duplicate was targeted for Camino 1.0 (this is 1.2); should this be retargetted to 1.0? (from bug 198162 comment 2) > No, Mozilla 1.2.1 behaves correctly, and stores two separate sets of login > information for the realm and for the web form. The two prompts are different > on Mozilla, too - for the web form, it offers that Password manager can remember > this logon (with Yes, No, and Never buttons) whereas for the realm it's a simple > checkbox on the login sheet itself. Also updating summary to grab the "keychain" bit from the dupe.
Component: General → OS Integration
Summary: Password auto-fill doesn't distinguish between HTTP authorization and HTML forms → Password auto-fill doesn't distinguish between HTTP authorization and HTML forms (only one keychain entry per site)
Comment 9•19 years ago
|
||
I'd just like to put in my 1.5c on this one since it is not only very annoying but basically drives me and others in my office away from Camino and back to the full Mozilla distribution every time. For those that this bug affects it's a deal killer when every other browser available behaves as expected and the bug is now over 2 years old (targetted for 1.2 !?!?). Each major release of Chimera-now-Camino that came out I would install with enthusiasm and start using up until this bug would strike again. I very much think that this would be a terrible bug to ship a 1.0 release with -- it's just flat out wrong behavior.
*** Bug 308696 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
I think that just because -most- people won't have an issue with this doesn't mean it shouldn't be fixed. Most websites don't adhere to W3C standards, but Camino won't be abandoning that, will it?
Comment 12•19 years ago
|
||
when did i say i wouldn't fix this?
Comment 13•19 years ago
|
||
I think Safari does the right thing here by using the Kind field, which is only available when using Keychain Services, instead of the legacy Keychain Manager. As we are not supporting Keychain Services until 1.1 or 1.2, it would be unhelpful to engineer a hack that fixes it whilst using Keychain Manager (which would have to be hacked into a special string in the path)
Comment 14•18 years ago
|
||
I sadly have to agree with Comment #9. I've been very impressed with Camino but the limitations of the password storage make the browser useless for me in my everyday work. Incidentally, it seems rather sad that this bug is still marked NEW after three years. I'm surprised that this behaviour hasn't hit the Camino developers hard since I would expect they would more commonly deal with multiple accounts, passwords, and authentication schemes on a daily basis. I'll be back to Camino the moment this is fixed!
Comment 15•18 years ago
|
||
<i>I'll be back to Camino the moment this is fixed!</i> I hate to "me, too!" but "me, too!" I have to deal with a set of development sites that are kept behind a general httpd auth, but that include CMSs after that authentication with their own password/username schemes. This particular issue means I can't use Camino without irritation several times a day. I haven't seen anything like this on any other browser, and I hope it gets fixed soon. Definitely a show-stopper for me in the mean time, though.
Assignee | ||
Comment 16•18 years ago
|
||
Everyone is aware that this is a bug. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting.
QA Contact: winnie → os.integration
Target Milestone: Camino1.2 → Camino1.1
Comment 17•18 years ago
|
||
I like the fact that Camino pre-fills the form credentials with the HTTP credentials if no saved form credentials exist. But if I enter a different one, and ask Camino to remember it, I don't expect it to change the HTTP one behind my back. Perhaps that's a useful compromise? This happens to me daily at work too, because of HTTP auth on the dev servers, and FORM auth in the web application being developed.
Assignee | ||
Comment 19•18 years ago
|
||
Taking; this will have to be fixed as part of the work necessary for bug 354975.
Assignee: mikepinkerton → stuart.morgan
Assignee | ||
Comment 20•18 years ago
|
||
(In reply to comment #19) > this will have to be fixed as part of the work necessary for bug 354975. By which I actually mean bug 202337
Assignee | ||
Comment 21•18 years ago
|
||
Fixed by bug 202337. Note that existing entries will continue to fill both until they are modified in some way (i.e., the username and/or password changes) for compatibility. New entries will be specific to the type they are created for.
Comment 22•17 years ago
|
||
Moving fixed "1.2" bugs to 1.1 where they were really fixed. Filter on CaminoFixed1.1 for bugmail purposes.
Target Milestone: Camino1.2 → Camino1.1
You need to log in
before you can comment on or make changes to this bug.
Description
•