173376 - embedders need access to necko's HTTP auth cache

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Darin Fisher]

embedders need access to necko's HTTP auth cache.  see related bug 60304, which
contains a proposed XPCOM interface.  since this is something we'll have to
freeze quickly, we might want to come up with something specifically for the
Java plugin.

Comment 1

[Bradley Baetz (:bbaetz)]

Re attachment 102817 [details]:

Why http-specific? ftp has auth, too. Even if it doeesn't support an auth cache,
I don't see why this has to be part of http by design, even if the
implementation is done that way to start with.

Besides, isn't the wallet stuff already frozen? Can't sun use that? We already
have an nsIPassword.idl in there

Comment 2

[Darin Fisher]

sun can't use wallet because that would still result in a two auth dialogs if
the java plugin needed auth credentials for a site before necko.  now that could
change if necko didn't pop-up prefilled auth dialogs, but that behavior is
probably not going to change.

good point about being protocol agnostic.  i'll give that some more thought.  we
may want to expose some of the RFC 2617 specific things like sending auth
credentials based on the URL path.  hmm...

Comment 3

[Bradley Baetz (:bbaetz)]

I get this icky feeling about embedders using parts of our networking stuff.
Getting access to this info isn't going to help if the webserver using an auth
method which we support by java doesn't (eg digest auth), or even the other way
arround (does java support NTLM auth)

Theres another bug somewhere on making the http auth cache stuff more generic.
If we did that, then the sun stuff could do the get/put stuff via that
interface, and so could the mozilla http stuff. That way things wouldn't have to
ask for this twice.

If we do do this, though, somone should make sure that the phoenix replacement
for wallet supports this interface :)

Comment 4

[Darin Fisher]

java only supports Basic auth; that's why it will be necessary to pass the auth
scheme through this interface.  i'm really thinking of making this two-level. 
we can introduce a simplified interface for the java plugin only, which will be
frozen soon.  later on we can develop a richer interface to necko's HTTP auth cache.

Comment 5

[Zhengyu Gu]

It is true right now, but may not for long. We get a lot of escalations for 
NTLM support, and network/security teams already have it ready. So it is just a 
decision away for NTML support.

Comment 6

[Darin Fisher]

interesting.  well, that means we should include username:password:domain for
this interface.

Comment 7

[Bradley Baetz (:bbaetz)]

I just think we should create/freeze this when its ready, rather than have a
frozen interface which we then have to support forever.

Comment 8

[Darin Fisher]

the java plugin needed this 2 years ago.  i think we should move forward and
provide something stable on which java and other plugins will benefit from.

Comment 9

[Darin Fisher]

looks like this isn't going to happen by mozilla 1.2; moving out to mozilla 1.3
alpha.

Comment 10

[Darin Fisher]

*** Bug 74171 has been marked as a duplicate of this bug. ***

Comment 11

[Darin Fisher]

nsIHttpAuthManager was introduced by the fix for bug 60304.  marking this bug
resolved FIXED.

Comment 12

[benc]

whitebox