377586 - Passwords created in Camino are not available in Safari

Status: RESOLVED WORKSFORME

(Camino Graveyard :: OS Integration, defect)

Description

[Shaun McDonald]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4pre) Gecko/20070408 Camino/1.1b+
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4pre) Gecko/20070408 Camino/1.1b+

If you save a password to the keychain through Camino, you cannot access that password through the auto fill feature in Safari. I think this has something to do with Safari being able to store multiple usernames for each domain, whereas Camino only stores one username per domain.

Reproducible: Always

Steps to Reproduce:
1. Go to a site in Camino that requires a login
2. Save the password
3. Go to Safari and access the same site.
Actual Results:  
Username and password fields not filled in in Safari.

Expected Results:  
Username and password fields to be filled in in Safari.

You can find the password by accessing the appropriate entry in Keychain Access.

Comment 1

[Stuart Morgan]

Safari pre-caches a list of domains for which there are stored passwords at startup, so you need to quit Safari between steps 2 and 3. If you can still reproduce this given that, please give specific sites where it happens, since it's  definitely not true in general.

Comment 2

[Shaun McDonald]

It appears there is an issue when there is multiple entries for the site in Keychain access. Some of the duplicate items are passwords that were saved in Safari at some point.

I have tried deleting the multiple entries in Keychain Access for amazon.co.uk, so that there is only one entry, and Safari will not enter the password like Camino, but it does enter the username automatically. I have restarted Safari and the same still occurs.

Which Kind of Keychain Access item is it that is used? I have both "Web form password" and "Internet password".

Comment 3

[Stuart Morgan]

(In reply to comment #2)
> I have tried deleting the multiple entries in Keychain Access for amazon.co.uk,
> so that there is only one entry, and Safari will not enter the password like
> Camino, but it does enter the username automatically.

Odd, I don't have any problem using a Camino-save amazon.co.uk password in Safari. Please run the following command in Terminal when you have only the Camino-stored password in your keychain, and attach the output here:
security find-internet-password -s www.amazon.co.uk
Or if the password is really stored under amazon.co.uk rather than www.amazon.co.uk, then 
security find-internet-password -s amazon.co.uk

> Which Kind of Keychain Access item is it that is used? I have both "Web form
> password" and "Internet password".

Web form password is a label Safari gives to form passwords it saves; the difference is entirely cosmetic.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Shaun, can you please respond to comment 3?

Comment 5

[Shaun McDonald]

Sorry for the delay in resonding. I'm nearing the end of my exams just now.

Removing all but one of the amazon.co.uk passwords in Keychain access then starting Safari meant that the username was filled in but the password wasn't filled in.

Removing all the amazon.co.uk passwords from Keychain Access, then resaving it in Camino. Then on restarting Safari the username and password was filled in.

It seems that old passwords in Keychain Access have a problem sometimes. The workaround is to delete the passwords for the relevant domain in Keychain Access, then resave them. Where Safari has a password for a different user account already stored, there seems to be a greater chance of a conflict as Safari seems to be able to cope with many usernames for each domain while Camino can only cope with one username and password per domain.

Comment 6

[Stuart Morgan]

Closing WFM then. You use of the term "old passwords" suggests that you are talking about a password that was stored with an older version of Camino; those are not going to be picked up by Safari until they are modified in some way.

Comment 7

[Vincent Danen]

I don't think this is resolved.

I'm just starting to use Camino more, mostly been using Safari.  So I created a password for the Safari service and in Keychain Access it shows as:

Name: members.oreilly.com ([e-mail])
Kind: Web form password
Date Modified: 07/17/06 7:19 PM
Keychain: vdanen

But going to login with Camino I have to enter my credentials, and Camino asks if I want to save it, so I click yes and in KeyChain Access I see:

Name: members.oreilly.com
Kind: Internet password
Date Modified: Today, 2:03 PM
Keychain: vdanen

They're obviously two different things, so this isn't a case of "old Camino" vs "new Camino" but a case of a serious PITA for people coming from another browser (Safari, OmniWeb, probably others) to Camino and having to re-enter everything (and end up with duplicate keychain items).

The first keychain entry has an ACL of allowing both Safari and OmniWeb.  Camino should be added to that list.

Now, if you say that "Internet password" vs "Web form password" is entirely cosmetic then fine, I'll take your word for it, but regardless, a Safari user moving from Safari to Camino will get hit (and annoyed) with this because it looks like Camino is using keychain (great!) but uses it differently than other browsers do.

I'm using Version 2007022813 (1.0.4), BTW.

I don't seem to have access to re-open this, but I think it should be re-opened.

Comment 8

[Vincent Danen]

Oh, another quick note.  I think you're right on the cosmetic part, but it looks like Safari is adding the account name to the Name field and this is where Camino is missing it.

Opening up both of the members.oreilly.com entries, the *only* difference is in the name (besides Kind, which doesn't seem to matter as I have older entries with "Kind: Internet password" that have ACLs for both Safari and Camino associated with them).

Maybe Camino needs to look for a Name entry that has the account name in it as well as one without (I'm not sure how Camino is doing lookups, I'd assume that the really important bits are only the "Account" and "Where" fields, but they are both identical in both entries).

Comment 9

[Vincent Danen]

Aha!  I found it.

On closer investigation, it seems like this is a problem with https logins.  For instance, in Safari, you'll have:

Where: https://www.foo.org/

but in Camino you get:

Where: http://www.foo.org:443

I didn't see it with the oreilly one because it didn't append the :443 to it, but the Camino-created one was http:// whereas the Safari created one was https://.

I think Camino needs to use https:// instead of http://...:443

Hmm... no, that's just part of it.  Tried with an internal svn access service which uses http auth but not over SSL, and the only discernable difference is that the Name is "isvn.annvix.ca" instead of "isvn.annvix.ca (vdanen)".  Passwords are stored the same, they both say "Internet password" for the kind, but Camino isn't seeing or wanting to see the "... (username)" one.

On the commandline:

vdanen@odin:~/.irssi/irclogs/2007/ >% security find-internet-password -s isvn.annvix.ca     
keychain: "/Users/vdanen/Library/Keychains/vdanen"
class: "teni"
attributes:
    0x00000007 <blob>="isvn.annvix.ca (vdanen)"
    0x00000008 <blob>=<NULL>
...

so security is looking for and pulling up the "... (username)" one by default, so why isn't Camino using it?  Shouldn't it be operating in the same way?

(Sorry for all of these posts, I just keep trying different things after I write).

Comment 10

[Stuart Morgan]

(In reply to comment #7)
> I'm using Version 2007022813 (1.0.4), BTW.

Camino's Keychain use has been completely rewritten since 1.0.4. Sharing passwords with Safare et al. is a new feature in the upcoming release, so any tests you are doing with anything but a recent nightly aren't valid. If you find issues even with a recent nightly, please open a new bug, since this bug is now very noisy.

Name, by the way, is also entirely cosmetic.

Comment 11

[Vincent Danen]

Ok, fair enough.  I'll give the nightly build a go and if I still have issues I'll report them.  Thanks.