Closed Bug 236969 Opened 20 years ago Closed 28 days ago

Camino doesn't access the Apple keychain entry for proxy password

Categories

(Camino Graveyard :: OS Integration, defect)

Product:
Camino Graveyard
Component:
OS Integration
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: Stuart.Lamble, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040208 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040208 Camino/0.7+

With OS X 10.3.2 (can't verify for earlier OS X releases), when you specify
proxy settings, you can also specify the proxy password (if needed). These
settings are stored in the keychain (seems to be the user keychain, rather than
the system), with a name according to the address of the proxy server, and the
where being something like ftp://proxy.address:port or http://proxy.address:port
(the protocol specifying the protocol being proxied, NOT the protocol to access
the proxy).

Camino doesn't use this information -- instead, it prompts you for the password,
with the option of saving the password in the keychain (presumably a
Camino-specific keychain entry). Camino should check for the existence of these
keys in the keychain, and make use of them if available, rather than asking.

Reproducible: Always
Steps to Reproduce:
1. Specify a proxy, with password, in Network Preferences.
2. Open Camino, and try to access a website through the proxy.
Actual Results:  
Camino prompts for the username and password, with the option of storing it in
the keychain.

Expected Results:  
Camino should check for Apple's keychain entry and make use of it if available.
If not, the current behaviour is probably the most appropriate (don't know the
guidelines on this from Apple; if in doubt... :)

Willing to investigate more deeply and submit a patch, but it might take me a
fair amount of time -- things are going to heat up at work soon (new hardware
coming in ... woo, new toys!), and I don't know that I'd be willing to spend my
weekends working on this. (Hey, at least I'm honest! :)
Stuart could you please update. I can't confirm this myself so I need some more
infor from you.
What do you need to know? I can easily provide whatever information you need
(the problem's still present in build 2004120508; I probably should update my
copy of Camino some time), I just don't know what more you need.

I'm looking at Keychain right now; the passwords are stored in a keychain entry
named "proxy.monash.edu.au" (the hostname of the system I'm using for a proxy),
of kind "Internet password". The "where" is as outlined in the original
description (eg: "https://proxy.monash.edu.au:80" for the HTTPS proxy).

Fixing this is on the list of things to do for me; it's just that when I saw
that a rewrite of Camino's keychain code was in progress, I decided to leave it
until after that was complete. I found it too hard to figure out what was going
on in the little time I have at work to play around with this stuff. :)
We need to kick this off on UNCO if it's a real bug, but none of us on the
triage team seem to have proxies available :-( so it's hard to judge for sure
(it seems like it could be).

Can you also test in a recent nightly to reconfirm the problem exists?

What does Safari do?

Do you suppose Camino's behavior is a result of bug 172842?


2005033008 -- still present.
Safari: prompts for access to the keychain entry with the usual "deny", "allow once", "always allow" 
options.

Regarding bug 172842, fixing that bug may (or may not) make it easier to fix this one, but I don't see 
them as one and the same. Camino can access the keychain; it's simply a case of it not knowing to do 
so. Changing the API used to access the keychain won't alter that.

I'll have to download the code and have a fiddle around in my own time; it'll be easier now that my mini 
has (finally! -- nearly three months after placing the damn order!) arrived. If there are any suggestions 
on where to look, I'd be grateful, although I can always spend time trawling through the code myself. ;)

In a lot of ways, this can be considered a feature request more than a bug, except insofar as the end 
user will probably be scratching their head as to why Safari can do this, whilst Camino can't.
(In reply to comment #4)
> 2005033008 -- still present.
> Safari: prompts for access to the keychain entry with the usual "deny", "allow
once", "always allow" 
> options.

I take this to mean Safari accesses the existing password in the proxy entry and
goes on about it's merry way, correct?

I'm going to go ahead and confirm this, -> OS Integration  

I think Josh is the one who's looked at the keychain stuff most recently, so he
might be able to give you some pointers on where to look.
Status: UNCONFIRMED → NEW
Component: General → OS Integration
Ever confirmed: true
> I take this to mean Safari accesses the existing password in the proxy entry
> and goes on about it's merry way, correct?

Correct. ("Its", not "it's", btw -- sorry, pet peeve.) Whether or not I get the information from Josh, I think 
I might grab the code today and have a fiddle tonight; I've been playing a bit too much Zelda so I might 
as well do something productive instead. :-) Whether or not it actually goes anywhere is another 
question entirely; I've been out of the coding game for too long.

Thanks.
Priority: -- → P3
Whiteboard: needinfo
Target Milestone: --- → Camino1.1
Stuart, did you ever have a look at this?  What happens if you explicitly add Camino to the list of apps allowed to access that entry in Keychain Access?

Simon, what sort of info did you have in mind when you added "needinfo"?
OS: Mac OS X 10.2 → Mac OS X 10.3
QA Contact: os.integration
Summary: Camino doesn't access the Apple keychain entry for proxy password. → Camino doesn't access the Apple keychain entry for proxy password
I did have a look at the code, and then ran screaming in terror; it was a bit too convoluted for me at the time. I do intend to try to figure out where the problem lies, but I suspect that a fix would mean either a special case for the proxy password (eurgh), or a major rewrite of the keychain code (eurgh). Neither option really appeals to me that much.

I've done a bit of Cocoa dabbling in the past few months, so I *might* be better placed to have a stab at a patch, but don't hold your breath; my coding habits of late haven't been that good, especially since I'm flat out at work at the moment.

As for explicitely adding Camino to the allowed apps for the keychain entry, I haven't yet tried it, but I doubt it'll do the trick. As best as I can tell, Camino is accessing a completely different keychain entry to Safari when it comes to the proxy password.

I really need to try setting up a test bed on my Mac at home so I'm not relying upon my work (dial-up) connection to play with this stuff ...

I know I've been dragging on this one, and I do apologise; it's not a major concern, so it's tended to be low on the list of things to do.
Stuart, we are currently looking for a Keychain implementation rewrite to take place. If you're still a student, consider Google's Summer of Code which may pay you to do the rewrite.

See: http://wiki.mozilla.org/Community:SummerOfCode06#Mac_Platform_Improvements
Alas, I'm no longer a student, and haven't been one for a good eight or nine years. Maybe I can claim as a student of the University of Hard Knocks? :D
Keychain bugs -> 1.2.
Assignee: mikepinkerton → nobody
Target Milestone: Camino1.1 → Camino1.2
This will hopefully become easier to fix once I land the second or third round of keychain changes; certainly the Camino end will have substantially better support for handling different auth types and protocols.

The issue at that point will be finding out if Gecko's callbacks give enough information to realize that we're dealing with a proxy so we can use the right protocol for the lookup (which is I would guess is one of the kSecProtocolType<Foo>Proxy values).
For my own reference, kSecProtocolTypeHTTPProxy and kSecProtocolTypeHTTPSProxy are the types involved here. I need an authenticating proxy server to test against to figure where and how Gecko calls into our code, so if anyone has any pointers that would be great.
Okay, I have one at least temporarily. nsIAuthPrompt doesn't give us the information we need to know it's a proxy so right now we assume it's an HTTP auth dialog and treat it accordingly. nsIAuthPrompt2 lets us ask which it is, and it looks like the API is less unpleasant in other ways, so I'll look into switching over to that.
Assignee: nobody → stuart.morgan
Doh; nsIAuthPrompt2 is trunk only.

We *could* consider doing an interim read-only fix for branch where we just check for proxy entries first and try them, but I'm not sure it would work out. Here's my brain-dump in case I can't remember later how I thought this might work:
- When we get a prompt request, first check the keychain for a system proxy password for that domain and port. If we find one there's a good chance that it's what we need, so just submit it without showing any UI (showing UI is messy, because if they do anything to cause a change it would save incorrectly). Remember that we tried this in a short-lived cache
- If we guessed wrong and it's a proxy, we should immediately get another prompt; if that happens, we can tell because of the cache, so we give up and fall back on what we do now.

Issues that come to mind:
1) If we guess wrong and it's not a proxy, they'll get a denied page without having seen any auth UI, which would be weird.
2) If we guess wrong, we just sent the wrong login info. Not so good.
3) It creates a different experience if it's saved from Camino vs. saved from Safari or the network control panel.
4) My assumption about getting re-prompted is based on the proxy I tested with; I don't know if that behavior can vary among proxies

I'm not too worried about 1 & 2, since doing the wrong thing would mean that there would have to be HTTP auth requests happening on the same server+port that the proxy is (or at least was when the password was saved) using, which seems exceeding unlikely. 3 kinda sucks though and 4 is a bit worrying.

It may just be best to punt this to 2.0 where we should be able to do the right thing.
If you need to punt it, punt it. I always thought of this as a minor bug - irritating, and slightly detracting from the OS integration that is one of the nice things about OS X, but not critical (since there's such a trivial workaround.) Evidence for this: there's been no duplication, and most of the CCs are Camino developers. :-)

I'm fairly sure that you'll be re-prompted with any given proxy - which proxy are you using? The one I can access is using squid, so if you're using something else, let me know, and I can report back fairly easily.
Whiteboard: needinfo
Target Milestone: Camino1.6 → Camino2.0
Stuart:

The correct "model" for Proxy Auth is the same as HTTP auth (which is a bit odd).

When a response comes, if it is 407, display the auth dialog w/ cancel.

If user selects "cancel", then display returned page (which carries an error message in HTML).

If user enters something, send the auth credentials in a new request.

If the auth credentials are correct, a non-407 will come back, and the normal behavior occurs. If another 407 is returned, request auth again.

(And basically loop forever if the user keeps trying, until they get it right or give up (hit cancel)).

---
Also, are you looking at how you store the passwd vs. how the Network panel does? I did a quick save test, and saw that gopher is saved as "gphx://hostname:port#/

I can check the rest of the proxy URL schemes when I have some more time...
Yes, I understand how it works; see comments 14 and 15. I know how to fix this for 2.0, I just don't have the time to do so while working on 1.6.
Priority: P3 → --
Pushing off of the 2.0 list; nsIAuthPrompt2 unfortunately isn't high enough priority to get done for 2.0 at this point.
Target Milestone: Camino2.0 → ---
Assignee: stuart.morgan+bugzilla → nobody
Status: NEW → RESOLVED
Closed: 28 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.