Closed Bug 60304 Opened 24 years ago Closed 21 years ago

Basic Auth doesn't work for Java

Categories

(Core Graveyard :: Java: OJI, defect, P1)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: sjoerd, Assigned: zhengyu.gu)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [eapp][adt2] jpibug)

Attachments

(8 files, 5 obsolete files)

rough draft interface to necko HTTP auth database
3.32 KB, text/html
Details
prototype nsIHttpAuthManager interface
1.77 KB, text/plain
Details
prototype of implement of the new version of nsIHttpAuthManager
14.05 KB, patch
Details | Diff | Splinter Review
updated patch following darin's comments
15.42 KB, patch
antonio.xu
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
Update OJI patch according to Darin 's comments
16.09 KB, patch
Details | Diff | Splinter Review
Update OJI patch for UTF-8 -> UCS2 convert
15.97 KB, patch
Details | Diff | Splinter Review
optimized patch
15.87 KB, patch
peterlubczynski-bugs
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
change out param from char ** to be const char **
1.65 KB, patch
jst
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review 
I have an intranet with Basic Auth, which uses a Java applet.
It works fine in Netscape 4: I just have to log in once.

With Netscape 6 I have to re-enter the username and password in a Java dialog.
And after I do that, I get a java.lang.NullPointerException somewhere in 
HttpURLConnection.getInputStream in the AppletClassLoader.
Sjoerd Visscher, Bugzilla normally does not handle Netscape 6 bugs, unless they
are reproducible in Mozilla. Can you reproduce this in a Mozilla latest build?
Thank you,
Fabian.
Oh, yes. I did that ofcourse.
I forgot to mention that.

But I'm not sure it is a Mozilla bug. 
It might also be a bug of the Sun Java plug-in 1.3.0_01
Blocks: 61681
->me
Assignee: gagan → darin
Component: Networking → Networking: HTTP
is this related to bug 59866?
*** Bug 60422 has been marked as a duplicate of this bug. ***
This depends on 61669.
Depends on: 61669
Try disabling the cache then see if it works.
Target Milestone: --- → Future
*** Bug 76192 has been marked as a duplicate of this bug. ***
*** Bug 103747 has been marked as a duplicate of this bug. ***
No disabling the cache does not fix this problem.

I'm marking this bug critical.

This is blocking some major applications from IBM.

I have tried all combinations of Mozilla/Netscape/JAva 1.3,Java 1.4 and none of 
them work.

Does anyone have any idea where to even start looking at this?

Do we think it is Java or browser?

My testcase is http://www.iris.com/mail/wmtestuser2.nsf 

user: wmtestuser2
pass: wmtestuser2
Severity: normal → critical
sounds serious... taking for 0.9.6
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: Future → mozilla0.9.6
hmm.. i tried the testcase w/ a linux build from 10/10/2001, and i don't see any
problem.  is this known to be a windows only problem?
win2k, Java 1.3.1

NS 4.78                 doesn't work (without any error in the JS console)
Mozilla 20011009        doesn't work (with error in the JS console)
IE5.0                   works
Seems to work for me right now on redhat 7.1 with 0.9.4.  It didn't work before.

thanks for the feedback, i'll give this a try with my windows build.
I'll check with the trunk tomorrow on Os/2.

The OS/2 Java plugin is based on the Linux plugin.

What Java version are you using on Linux?
s/JS Console/Java Console
*** Bug 104410 has been marked as a duplicate of this bug. ***
*** Bug 106457 has been marked as a duplicate of this bug. ***
I've put a new URL in that shows this problem better.

Userid is blee, password is blee.

I'm starting to believe this is a Java problem, but I'm not sure.

I'm using the latest 6.2

Here is the exception from the console when this happens:

java.lang.NullPointerException
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown 
Source)
	at 
sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown 
Source)
	at 
sun.plugin.protocol.jdk12.http.HttpURLConnection.checkCookieHeader(Unknown 
Source)
	at 
sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(Unknown Source)
	at java.net.HttpURLConnection.getResponseCode(Unknown Source)
	at sun.applet.AppletClassLoader.getBytes(Unknown Source)
	at sun.applet.AppletClassLoader.access$100(Unknown Source)
	at sun.applet.AppletClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.AppletClassLoader.findClass(Unknown Source)
	at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadCode(Unknown Source)
	at sun.applet.AppletPanel.createApplet(Unknown Source)
	at sun.plugin.AppletViewer.createApplet(Unknown Source)
	at sun.applet.AppletPanel.runLoader(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
URL: http://blee:blee@nis.acs.uci.edu/~str...
I've been asked by my management to mark this blocker.

Can anyone point me to the place where mozilla passes URL information to the 
plugin?

Mozilla uses the userid/password to actually retrieve the applet, is there 
someplace where the URL of the applet is passed to Java?

Maybe this is missing the information?
Severity: critical → blocker
cc'ing some of the plugin folks...
A good place to start looking may be in nsPluginHostImpl::SetUpPluginInstance().
Here you already have some windows-only Java code plus a nsIURI is passed in.
mkaply: seems like you are investigating this bug... would you like to own it?
moving this to untargeted (for now) until we have a better idea of what is going on.
Target Milestone: mozilla0.9.6 → ---
We are looking at it and needless to say, we are getting strange and 
different results.

When you go to the URL in the bug with NS 6.2 and the Java that comes 
with it (I don't remember the version right now), you enter a userid 
and password for Java, but the applet doesn't start.

When you do this using OS/2 and Java 1.1, the applet does start.

We're currently investigating why the second dialog comes up at all 
because in the proxy authentication case, Java IS able to get the 
authentication info from the browesr, so there must be some way to 
pass the information.

what would be great is to have different people try this on the trunk 
with different OSes and Java and post their results.
win2k build 20011104.. and JRE 1.3.1
The page above works after I entered the password in the java plugin.

But there this URL different compared to the last one.
This one needs only basic auth for Java, the last URL needs basic auth first for
mozilla nd then also for the Java.
by putting blee:blee@ before the URL, I was causing Mozilla not to ask 
for the authentication.

You can just remove those and then Mozilla will ask and then Java will 
ask.
oh sure - sorry I'm stupid (i have not noticed the blee@blee in the URL)
Mozilla aks for the Basic Auth and Java asks again - wfm
Relevant info from Sun bugtraq bug 44518282 - 
http://developer.java.sun.com/developer/bugParade/bugs/4518282.html

Sun's answer:

After browser been challenged, browser adds Proxy-Authorization header for
subsequence Http requests. But the value of the header is stored somewhere in
browser side, there is not API for plugin to obtain the value right now.
Whiteboard: [eapp]
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Keywords: nsbeta1+ → nsbeta1
blocker doesn't make sense... reducing to critical.

-> mozilla 1.0.1
Severity: blocker → critical
Target Milestone: --- → mozilla1.0.1
-> badami for investigation, changing target milestone to mozilla 1.0 to better
reflect nsbeta1 nomination.
Assignee: darin → badami
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0.1 → mozilla1.0
Blocks: 128892
Keywords: nsbeta1+
I'm going to add some addiitonal info into this based on research we (IBM) have 
done.

We believe that the very basic problem here (double authentication dialogs) is 
an architectural issue with the Java plugin. There is a way for the plugin to 
query proxy info from the browser, however, so maybe there is a way to get the 
authentication info?

The problem with the NULL pointer exception seemed to only happen with Java 1.3 
- Java 1.3.1 fixed this, so that after typing in the second userid and password, 
things worked.

Java 1.4 appears to have completely broken this however - our pages that use 
authorization are completely broke.

So given all that info, I'm not sure there is anything that can be done on 
just the Mozilla side. We have opened bugs with Sun on these items.

Incidentally, the core issue is that on 4.x, all network requests for Java were 
routed through the browser network layer, so none of this was an issue. With the 
plugin, Java does its own network requests.

Maybe the best solution here is to figure out a way to have the plugin route 
network requests through the browser...
Keywords: nsbeta1
*** Bug 129103 has been marked as a duplicate of this bug. ***
Sorry Guys,

but I can not reproduce all of your problems. The java-applett works fine for me.

If I open

http://nis.acs.uci.edu/~strombrg/go-games

enter the username and password twice (for the site and later for the
java-dialog) the java-applett will be loaded and it works.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
Java(TM) Plug-in 1.4.0-rc-b91
Actually, you have duplicated it perfectly. Once you authenticate with the
browser using Basic authentication you should NOT have to authenticate again to
the Java plugin.
Actually the same java not authenticated problem can be view with any webmin
installation.

Just go to the filemanager and you will notice that it gives you a exception
during the initialization. 

Looking at the webmin.log shows, that the two http requests from the java applet
are not using a username/password.

I can give more details if required to reproduce it with webmin.
Looks like this is a documented shortcoming of the java plugin at this moment:

http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/faq/troubleshooting.html

Q: Some web/proxy servers require users to login for authentication. When I used
the browser to access this server with Java Plug-in, two login dialog boxes
appeared. Why?

A: Normally Java Plug-in will download the applets using its own connection. If
the web/proxy server requires login, the browser will first encounter the
request and bring up a login dialog box. After the HTML page is downloaded, Java
Plug-in will try to download the class or jar files for the applet. However,
since Java Plug-in has no access to the login information that the browser
previously obtained, it will bring up its own login dialog box. 
Can't agree with #40

You can use the java plugin with IE 5.x too, and there the authentication infos
get are still present when the applet does requests to the server.

No idea if IE wrapps the request with the auth. infos, or if the applet knows
about the authentification. (Probably the applet knows about the
authentification and can use it.

André
Reassigning to OJI component and component owner.
One option is to get the Java n/w libs to start using Necko.
Alternatively, will have to teach the OJI plugin to query Necko for plugin info
and expose such API.
Assignee: badami → joe.chou
Component: Networking: HTTP → OJI
*** Bug 119924 has been marked as a duplicate of this bug. ***
bug can be tested via http://gemal.dk/test/javajava.html log in with username
and password "test"
URL: http://blee:blee@nis.acs.uci.edu/~str... → http://gemal.dk/test/javajava.html
Wouldn't delegating all networking calls to Mozilla through protocol handlers be
a good general solution for this and other bugs such as user agent strings and
cookies?
*** Bug 134621 has been marked as a duplicate of this bug. ***
adt1 to status whiteboard
Whiteboard: [eapp] → [eapp][adt1]
We have shipped with this one for several releases. Changing to ADT2.
Whiteboard: [eapp][adt1] → [eapp][adt2]
ccing Sun's Java plugin folks on this one.

It looks like that currently there is no way for Java plugin to know the
authentication data on the browser side.

Is Pactrick's suggestion (through protocol handler) a possible solution?

It may take some time for a good design and implementation. In the meantime,
entering user id and passwd twice is inconvinent, but is it really a blocking issue?
Currently this bug has been assigned to Sun's Java plugin group (with an
internal bug number), but it is NOT considered as a high priority bug. 
If there are valid reasons why this bug should be a high priority bug, please
list them here, so the bug can be re-evalueated.

Re-assign the bug to Zhengyu Gu, who is the assigneer of the Sun's internal bug.
Assignee: joe.chou → zhengyu.gu
Whiteboard: [eapp][adt2] → [eapp][adt2] jpibug
#40 is the correct description of the cause of the double logon. Before Netscape 
6 and Windows XP, applet tag is handled by JVM bundled with browser, which uses 
browser side of HTTP capability to download applet, so there is only one login 
request.

Netscape 6/Windows XP use Java plugin to handle applet tag, and Java plugin uses 
Java side implementation of HTTP connection to fetch applet, not though browser, 
so there is second logon request been generated.

To fix this, Java plugin needs browser side support to get previous 
authentication result to avoid the second challenge. There will not be a fix 
until browser side provides such APIs.


In response of #51 comment :

If you want use applet on a secure wen site, then you must write 2 time you logging.
Did you think a user will do thit to every web site i'll visite ?
To my part, i avoid all this solutions, because it laborious.
And all my clients said to me that they don't understand this double logging ;-((
this bug seems to be a "hot potato" exchange between Sun and Mozilla.

Joe: more and more, large enterprises (at least mine) give to all their
employees free access to the internet. To control and limit, they use a proxy
with authentication.

Given the choice between a browser which does not require double authentication
and one which needs it, what do you think a user will choose?

The cause of this bug is well identified but nothing happened in one and a half
year.

Is SUN not promoting Java applets anymore?
in response of # 53.

I'm devellopping soltion on web server secure, on intranet, there are not
solution  of proxy applicable (and I can ask webmaser to install it ! )

pdf plugin don't ask the loggin ! then I don't understand why sun java plugin
ask it ?
Ok it is bogue of Sun. I find there lot of bogue on JVM of SUN (then I ask
myself why they try to make a JVM 1.4, not compatible with preview version (or
there lot of bogue ...))

Actualy, to my solution there are 2 solutions : IE(v4-6)  and Netscape(v<6) with
Java 1.1.8 ! I regrest this ;-((
Depends on: 136856
We too develop web applications and for some special client side things we use
applets.

I can only agree with comments #53 and #54.
I think comment #45 points toward the solution if practicable. 

Perhaps sun tries to push webstart ?
> pdf plugin don't ask the loggin ! then I don't understand why sun java plugin
> ask it ?
Do you see any difference between java and pdf at all?
I think you missed the point.

When I identify myself against a website with my user/password in the webbroser,
then I don't see any logical reason why a "subcomponent" of the very same
browser in the same session should again ask me for my name/password.

What if I have onetime passwords ?

It is just ridiculous to have to login multiple times from the same Application
to the same server.

Of course there are actually technical reasons why it's so, but the systems are
designed to help the users and not to ask them the same question many times.

Just imagine you would have to login each time you start a application on the
desktop...
Sun BugId: 4518282
The reason plugins other than Java work is because they use the plugin APIs to 
do their networking.
I know another big software vendor who always trys to do standard things "the
other way" ;-)
Depends on: 135840
If I got it correctly, here is how the problem will be resolved: first 135840
(assigned to Pactrick Beard) needs to be fixed, so that there will be a way to
get the browser's authentication results for Java plug. Then Zhengyu can make
changes on Java plugin to utilize the newly available information to avoid
redundant authentication, and this bug will be fixed.

Now, when can this fix be available? Currently, 135840 is not targeted yet, so I
don't think this bug can be fixed for moz1.0. 

I agree that this bug should be fixed ASAP, but I disagree that this is a
blocker. Can the person who stamped "nsbeta1+" on this bug do a review, and
adjust the serverity accordingly.
OS: Windows 2000 → All
Hardware: PC → All
No longer depends on: 136856
any chance of getting relevant cookies passed along as well?
JPI already uses the browser cookies, at least in my testing. Look at the JPI 
1.4.0 developers guide:

http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/cookie_support.ht
ml

This bug is just about HTTP BASIC Authentication. If you are having a problem 
with the JPI 1.4.0 cookie handling in Mozilla, please file a new bug (and CC 
me, since I will deploying an applet using this cookie mechanism soon).
thanks Brian -- my test conditions were wrong, it does indeed work.
I would like to report exactly the same behaviour for Mozilla RC1 (for
OpenVMS). Java data as from Mozilla:

Java(TM) Plug-in 1.3.1-3-BUILD-020324-08:42

    File name: /sys$common/cswb/plugins/libjavaplugin_oji.so
Java(TM) Plug-in1.3.1_02

I'm using the FAST JVM
Proposed relnote: When going to a site that requires the user to authenticate
with HTTP to download a Java applet that also requires authentication, the user
will have to login twice with the same username and password.
Keywords: relnote
Alas, even that is not true. It doesn't matter what I enter, NOTHING is 
accepted. Even worse, I suspect that if more than one class is to be 
downloaded: I will have to enter username/password for each class.
re comment 67, what plugin are you using? not all java plugins are created equal. the following are all different and behave differentlynetscape communciator 4 [1.1.x]Macintosh Runtime for Java [1.1.x]MacOSX [1.3]Sun [1.3,1.3.1,1.4]IBM [1.3, ...]Also note that the behavior of sun and ms's jre's in IE are as irrelevant as the behavior of Netscape's JRE in NC4 because they use a different architecture (ActiveX and native integrated respectively).That said, I think I'll add the following to the relnotes:you may experience multiple login requests or java applet failure for sites that require authentication and contain Java applets. This occurs because the Java Plugin is not using mozilla to retrieve the class. Sun JRE1.3.1 is reported to work better than 1.3.0.x and 1.4.
No longer depends on: 61669
See comment 65: 

Java(TM) Plug-in 1.3.1-3-BUILD-020324-08:42

    File name: /sys$common/cswb/plugins/libjavaplugin_oji.so
Java(TM) Plug-in1.3.1_02

as downloaded from compaq. Usually, I'm using the FAST JVM - but that should 
not matter (I think?)

I could try older java machines?, I will also try to get some more info on the 
data passed over the connection.

The server side data:

MS IIS 4.0 combide with NetIt Central
Authentication via Firewall (Checkpoint-1) combined with Radius(MS IIS 4.0)
server
I could not get any authentication data.....I will try tcpdump on my side to 
see what's passing

Willem
Keywords: mozilla1.1
Previously, there were couple meetings discussing the possible solution to this
bug among Netscape and Sun's engineers. Then the discussion was suspended due to
other higher priorities. The following is extracted from Patrick Beard's
04/30/02 email about a proposed solution to this problem just before the
suspension, which we can now use as the re-starting point to seek the solution
of this issue:

"If we want to obtain the authoriztion header for s site that has already been
authenticated by Necko, we can open a channel to the same URL using Necko.
Here's some approximate code:

nsCOMPtr<nsIChannel> chan;
NS_NewChannel(getter_AddRefs(chan), NS_LITERAL_CSTRING("http://www.foo.com/");
if (chan) {
   nsCOMPtr<nsIHttpChannel>httpCnan(do_QueryInterface(chan));
   if (httpChan) {
      nsCAutoString val;
      httpChan->GetRequestHeader(NS_LITERAL_CSTRING("Authorization"), val);
      if (!val.IsEmpty())
         printf("creadntials=%s\n", val.get());
   }
}
...

Now we can design a new interface, in cooperation with the Necko team, say it's
called the nsIAuthCache (Darin Fisher preferred nsIHttpAuthCache), that would
internally use code like the above. Please don't add this code to your plugin,
because it would require hard links to the browser."


#70 is not exactly what we want. The reason is browser and plugin may use 
different proxy server in corporation environment.

If browser uses automatic configuration script, and script uses some kind of 
load-balancing to balance load among multiple proxy servers, then  browser and 
plugin may end up using different proxy server, and the credential plugin gets 
from browser will not be valid. It is VERY unlikely that user has different 
username/password among the different proxy server.

So, what we want is having browser return username/password pair for the 
url/schema/realm.


Hello,
I can confirm comment #67.
This is very anoying. 
It renders the Mozilla browser useless for us.
Sometimes I have to enter the user/pw 20 - 50 times!!!!!!!!!!!!!!!!

Bye
  Rainer Tammer
As strange as it may seem, and contrary to other reports on this page, the
applet authentication works fine for me in Mozilla 1.0, provided that I use JRE
1.3.x, and not 1.4. Only if JRE 1.4 is installed then user needs to enter
username and password twice. My website uses only https. There are many
interesting comments about this matter in Sun's Java bug database: 
http://developer.java.sun.com/developer/bugParade/bugs/4518282.html
Off topic, there remarks are probably true also for Internet Explorer 6.
this is a message i sent to patrick beard describing roughly what an interface
to necko's HTTP auth database might look like.	it still needs some work in
order to support other types of auth such as digest or NTLM (though mozilla
does not yet support NTLM).
Depends on: 173376
Ccing OJI folks.
Blocks: 127597
Keywords: mozilla1.1 → mozilla1.4
Hello,
the main problem is not that I have to enter the password twice (one time for
the proxy and one time for Java). 

The main problem is that I have to enter the password numerous times for Java.

If I connect to a HP switch (for example) I have to enter the Password 3 or 4
times. If I use IE 5.5 / 6.0 I have to enter the password ONE time. What is the
difference between Mozilla and IE? I have installed Java 1.3/1.4 in IE 6.0.

I want to rollout Mozilla to 800 Desktops. This bug is clearly a showstopper for us.

Bye
  Rainer Tammer
*** Bug 188309 has been marked as a duplicate of this bug. ***
*** Bug 188367 has been marked as a duplicate of this bug. ***
It seems relate to two kind of bug (see comment #76):
1. Enter the password twice (one time for the proxy and one time for Java).
2. Enter the password numerous times for Java Applet.

In fact, one way can solve the both:

Store Authorization/user/password on browser side and provide API in OJI modules
for JPI,
JPI can invoke this API to get Authorization/user/password.
1. the second Authorization for applet can be passed if java and proxy use same
Authorization mechanism.

2. all applets that use same Authorization mechanism needn't authenticate again

if user exactly use different Authorization mechanism, inputting password again
is reasonable.
There is only one method need to be provided for JPI:

like this protocol:

AuthenticationInfo getAuthenticationInfo(String protocol, String host, int 
port, String scheme, String realm) 

Zhengyu:

Please explain AuthenticationInfo structure for us

Thanks!
QA Contact: tever → petersen
Hi, OJI 's peer and owner:

can we export the

struct authenticationInfo {
    LPSTR lpszUserName;
    LPSTR lpszPassword;
}; 

AuthenticationInfo getAuthenticationInfo(String protocol, String host, int port,
String scheme, String realm)
for Java Plugin on OJI side (for example: in nsJVMManager.cpp:

nsJVMManager::GetAuthenticationInfo)?

Thanks!
My investigation here. 
1. Target:
IN                  OUT
------------------------------
protocol            user name
host                password
port
scheme
realm
------------------------------

2. Current:
nsHttpAuthEntry  <--  nsHttpAuthCache    <--     nsHttpHandler          ?      
  OJI
-------------------------------------------------------------------------------------------------
-                     GetAuthEntryForDomain      this->get()->AuthCache()         ?
host                  Y
port                  Y
scheme                -
realm                 Y
user name
password

3. To do:
nsHttpAuthEntry  <--  nsHttpAuthCache    <--      nsHttpHandler      *<--*     
   OJI
-------------------------------------------------------------------------------------------------
-                     GetAuthEntryForDomain  |    this->get()->AuthCache()    |   ?
host                  Y                      |                                |
port                  Y                      |                                |
scheme                -                      |                                |
realm                 Y                      |                                |
user name                                    |                                |
password              *getAuthenticationInfo*|    *and here, frozen?*          |
  *call the nsHttpHandler (service)*

4. Test:
nsJVMManager.cpp - build ok.
1. #include "nsIHttpProtocolHandler.h"
2. static NS_DEFINE_CID(kHttpHandlerCID, NS_HTTPPROTOCOLHANDLER_CID);
3. nsJVMManager::PostEvent(PRUint32 threadID, nsIRunnable* runnable, PRBool async)
{
    nsresult rv;
    nsCOMPtr<nsIHttpProtocolHandler> for_auth_get =
do_GetService(kHttpHandlerCID, &rv);
    if (NS_FAILED(rv)) return rv;

5. Issues
- what other protocols besides http?
- how about proxy support?
- how about NTLM support?
- if necko interface was frozen?

Zhengyu, I think NTLM is a transportation layer authentication, not an
application layer auth. It just use the HTTP style data structure and
handshakeing process to establish a connection. In another word, the purpose of
 NTML is to apply a channel, not a url. Windows system will take care of this
for mozilla. I *guess* both mozilla and java applet needn't to auth again after
the Windows desktop logged in. So we won't care about it. Right?

Calvin
5.
- what other protocols besides http?
  protocol will be http/https

- how about proxy support?
  proxy authentication should be addressed.

- how about NTLM support?
  JRE will support NTLM with release 1.4.2, so this interface has to support it.
  NTLM is NOT transportation layer security. It is a Microsoft proprietary 
authentication scheme, and very popular in Windows Network.
Darin:

About NTLM, do you have some suggestion?

Thanks!
Hi, *,
My approach here. Just a prototype. Welcome comments.

goal: necko export an interface, call it in oji.
approach:
1. export a method, add the following lines to nsIHttpProtocolHandler.idl
    /**
     * Get authentication information, see bug #60304
     */
    void GetAuthInfo(in string protocol, in string host, in long port, in string
scheme, in string realm, out string username, out string password);

2. implement it: add the following method to nsHttpHandler.cpp
NS_IMETHODIMP
nsHttpHandler::GetAuthInfo(const char* protocol,
	                   const char* host,
                       PRInt32 port,
			   const char* scheme,
			   const char* realm,
			   char** username,
			   char** password)
{
    nsresult rv = nsnull;
    const PRUnichar *uname, *pwd;
    nsHttpAuthEntry *entry = nsnull;
    rv = mAuthCache->GetAuthEntryForDomain(host, port, realm, &entry);
    if (NS_FAILED(rv)) return rv;
    uname = entry->User();
    pwd = entry->Pass();
    *username = strdup_if(NS_ConvertUCS2toUTF8(uname).get());
    *password = strdup_if(NS_ConvertUCS2toUTF8(pwd).get());
    return NS_OK;
}

3. call from oji, as Joshua pointed, I choose nsJVMManager.cpp
3.1 add interface ID like this,
static NS_DEFINE_CID(kHttpHandlerCID, NS_HTTPPROTOCOLHANDLER_CID);
3.2 include relative header file,
#include "nsIHttpProtocolHandler.h"
3.3 call in nsJVMManager.cpp::PostEvent like this, (hard code, only for test)
    nsresult rv;
    nsCOMPtr<nsIHttpProtocolHandler> for_auth_get =
do_GetService(kHttpHandlerCID, &rv);
    if (NS_FAILED(rv)) return rv;
    char* un = NULL;
    char* pd = NULL;
    rv = for_auth_get->GetAuthInfo("HTTP","marathon.prc",80,"basic","Protected
Area", &un, &pd);
    if (NS_FAILED(rv)) return rv;

i built it and tested, un and pd are correct. :)

issues:
1. is it correct/sensible solution?
2. can we apply it on https? (Seems ok.)
3. how about NTLM?
4. scheme is no use here because nsAuthCache->GetAuthEntryForDomain only use 4
parameters (host, port, realm, &entry). why doesn't it use scheme? shall we
double check scheme here?
5. anything else?

oh, need to release the char** pointer. I forgot it. :(

Calvin
calvin: getting auth info from necko is one thing, but what if the java
component is the first to authenticate?  then how will OJI inform necko of the
new username and password?  seems like we need to provide OJI with a way to set
and get auth info.  i'd prefer introducing a new interface for this instead of
using nsIHttpProtocolHandler.  how about nsIHttpAuthManager.
ooh, could we have a way to clear all auth info on nsIHttpAuthManager as well?  ;)
Darin,

Yes, we need to confirm the user case. Currently I'm dealing with this one.

A web server require basic or digest authentication on http to protect a special
resource, which is a html page that contains a java applet.

As I think, there're 2 authentication process.
1. mozilla pass the authentication of web server and get the html page
2. mozilla parse the html page and invoke jvm via oji

In this case, there is a one-way authentication infomation transfer, from necko
to oji, *NO* need to transfer from oji to necko.

Is there any other user case that we need pass authentication information from
oji to necko?

Thanks.

Calvin
calvin:

suppose you load a page on http://foo.com/dir/a.html and it references a java
class file at http://foo.com/dir/a.class.  suppose no authentication was
required so far.  now, the java applet could connect back to foo.com, right? 
and couldn't it try to load http://foo.com/whatever/c.html?  what if that
document requires authentication?  what if the user later on browses to
http://foo.com/whatever/c.html?  isn't this possible?
Darin,

You're right. We need such interface. Do you have the prototype? What's your
plan, and the schedule?

Calvin
Calvin:

http://bugzilla.mozilla.org/attachment.cgi?id=102187&action=view is the
interface definition you want. there are get and set methods in that interface.

But if that interface can not meet OJI's request, we need to update it. (Joshua,
can you review this interface from the perspective of OJI's request and give out
update suggestion?)


Darin, is it right? 


About authentication, there is something incompatible between Java and Mozilla:

1. There is no "PATH" conception in Java 's authentication.
So, Mozilla need default path of authentication, is that "/"?

2. JPI side have not prepared to set authentication to browser side.
Zhengyu/Xiaobin, please prepare protocol for this issue. Thanks!
Is void setAuthenticationInfo(String protocol, String host, int port,
String scheme, String realm, AuthenticationInfo authinfo) OK?

3. There is only user/password exchange between JPI and Browser (no challenge).
Zhengyu/Xiaobin, is that right? 

There is also something incompatible between JPI 's requirement and the rough
draft interface.
I modified. Darin, please verify. Thanks!

At last, need to define httpsAuthEntry interface? or we implement both
https/http as HTTP Auth interface?


interface nsIHttpAuthEntry : nsISupports
{
  /* auth challenge from 401/407 response */
  readonly ACString challenge;

  /* auth challenge scheme parsed from challenge (e.g., "basic") */
  readonly ACString scheme;

  /* auth challenge realm parsed from challenge */
  readonly ACString realm;

  /* path underwhich auth entry applies */
  readonly ACString path;

  /* stored username for this challenge */
  readonly ACString username;

  /* stored password for this challenge */
  readonly ACString password;
};

interface nsIHttpAuthManager : nsISupports
{
  /**
   * Lookup an existing auth entry for the given URL (<host:port><path>)
   */
  nsIHttpAuthEntry getAuthEntryForPath(in ACString aHostPort,
                                       in ACString aPath);
                                       
  // If not use scheme/realm as parameter, can we get single nsIHttpAuthEntry?
  /**
   * Lookup an existing auth entry for the given URL, scheme and
realm(<host:port><path><scheme><realm>)
   */
  nsIHttpAuthEntry getAuthEntryForPathSchmeRealm(in ACString aHostPort,
                                       		 in ACString aPath,
  				       		 in ACString scheme, 
  				       		 in ACString realm);
  /**
   * Lookup an existing auth entry for the given challenge
   *
   * @param aHostPort host:port from URL
   * @param aChallenge challenge string from 401/407 response
   * @param aProxyAuth if true, challenge originated from a 407 response
   * @param aAllowPrompt if true, user may be prompted for username and password
   */
  nsIHttpAuthEntry getAuthEntryForChallenge(in ACString aHostPort,
                                            in ACString aChallenge,
                                            in boolean  aProxyAuth,
                                            in boolean  aAllowPrompt);

  /**
   * Create/modify auth entry (empty challenge string clears auth entry)
   */
  void setAuthEntry(in ACString aHostPort,
                    in ACString aPath,
                    in ACString aChallenge,
                    in ACString aUsername,
                    in ACString aPassword);
                    
  /**
   * Create/modify auth entry
   */
  void setAuthEntryForSchmeRealm(in ACString aHostPort,
                                 in ACString aPath,
                    		 in ACString scheme, 
  		    		 in ACString realm,
                    		 in ACString aUsername,
                    		 in ACString aPassword);               
};
This is a prototype of implementation of "HTTP auth database interface" posted
by Joshua (#93). There are still several issue needed be addressed.

1. In the interface, the orginal first argument for function such as
"getAuthEntryForPath" is "in ACString aHostPort". I modify it to 2 arguments:
"in ACString aHost" and "in PRInt32  aPort", which is more convinient for OJI
module's invoking.

2. The implementation of "nsIHttpAuthManager" is almost based on
nsHttpAuthCache. But nsHttpAuthCache has a little difference to
nsIHttpAuthManager, which causes issues below:

    2.1 (line 278) nsHttpAuthEntry has no "scheme", which is needed by
nsIHttpAuthEntry. "challenge" contain "scheme", right? so we can parse "scheme"
from "challenge".

    2.2 (line 362) GetAuthEntryForSchemeRealm pass "scheme" and "realm", but
nsHttpAuthCache take only "realm" to get an entry. Is this a fault in
nsHttpAuthCache? (using "scheme" and "realm" is reasonable)

    2.3 (line 388) nsHttpAuthCache doesn't provide searching by "challenge". Do
we really need this interface? If so, we must add a function to
nsHttpAuthCache, right?

    2.4 (line 401 & 406) when set auth entry, "realm" and "crendital" can be
parsed out of challenge, right?

    2.5 (line 427) In nsHttpAuthManager::SetAuthEntryForSchmeRealm, there is no
crenditial, can it be nsnull?
>"in PRInt32  aPort"

IMHO, a PRUint16 for the port would be more appropriate, because it exactly
covers the range of possible ports.
Since nsHttpAuthCache use PRInt32 for "port", I use PRInt32 for "port" in the
interface for coincidence.
that's not a good enough reason. if the other place is wrong then file a bug to
get it fixed.
timeless, biesi:

PRInt32 has been used to represent ports in necko everywhere.  sad, but true. 
and it is part of our frozen API (nsIURI::port,
nsIProtocolHandler::defaultPort).  i don't think there is any point to changing
that now.  let's stick with what we've got... at least then we can be consistent
across interfaces ;-)
along this patch, I also updated the questions

1. I parse "scheme" from "chanllenge" when nsIHttpAuthEntry::GetScheme. The
same thing has been done in nsHttpChannel.cpp, so I think it's right.

2. For "GetAuthEntryForSchemeRealm", I am not sure why need "scheme" and
"realm"
simultaneously. Each "realm" has an unique "scheme". So use "realm" to query is
better, just like the interface of nsHttpAuthCache.

3. In interface "SetAuthEntry", how to get "credential" before invoking
"nsHttpAuthCache::SetAuthEntry".

3. The biggest question lies in "SetAuthEntryForSchmeRealm" interface. This is
actually the one JPI will use. But JPI seems to provide only "scheme", "realm",
"username", "password". I am not sure how to use this information to generate  

"credential" and "challenge", which is needed by
"nsHttpAuthCache::SetAuthEntry".
Attachment #113984 - Attachment is obsolete: true
Comment on attachment 114288 [details] [diff] [review]
updated patch for implementation of "necko HTTP auth database interface"

>Index: netwerk/build/nsNetCID.h

>+#define NS_HTTPAUTHMANAGER_CID \

please list contract id and class name here as well, e.g.:

#define NS_HTTP_AUTHMANAGER_CONTRACTID \
    "@mozilla.org/network/http-auth-manager;1"
#define NS_HTTP_AUTHMANAGER_CLASSNAME \
    "nsHttpAuthManager"


>Index: netwerk/build/nsNetModule.cpp

>+    { "HTTP Auth Manager",
>+       NS_HTTPAUTHMANAGER_CID,
>+       NS_NETWORK_PROTOCOL_CONTRACTID_PREFIX "httpauthmanager",

this is the wrong contract id.	nsHttpAuthManager does not implement
nsIProtocolHandler, so it should not have a contract id prefixed
with NS_NETWORK_PROTOCOL_CONTRACTID_PREFIX.  please see
nsIProtocolHandler.idl for more info regarding this contract id. 
use the contract id i mentioned above.


>Index: netwerk/protocol/http/public/nsIHttpAuthManager.idl

>+ * are Copyright (C) 2002 the Initial Developer. All Rights Reserved.

(C) 2003   ;-)


>+[noscript, uuid(0aa50346-e6cf-44e2-bfde-358ad34f6200)]

why can't these interfaces be scriptable?  is there a reason to prevent
Javascript from accessing these interfaces?


more comments shortly...
Attachment #114288 - Flags: review-
>>+[noscript, uuid(0aa50346-e6cf-44e2-bfde-358ad34f6200)]
>why can't these interfaces be scriptable?  is there a reason to prevent
>Javascript from accessing these interfaces?

The auth cache is secure information. I doubt it's not safe if enable Javascript
to visit the auth cache. In addition, there seems no need to let Javascript get
auth info.

heikki, can you give some advise? 
Louie,

but only javascript with chrome privileges will be able to access these
interfaces.  javascript from the web would be unable to access them.  so, by
making these interfaces noscript, all you're doing is preventing someone from
using them with a javascript xpcom component.  there doesn't seem to be any
value in limiting these interfaces like that.
Attached patch updated patch (obsolete) — — Splinter Review 
According to darin's comments, I have updated the patch.
Darin, can you spare sometime to review this one? Thanks!
Attachment #114288 - Attachment is obsolete: true
Attachment #115824 - Flags: review?(darin)
so, i've given some more thought to this problem, and i came up with what i
think the interface should look like.  i've tried to purposely limit this
interface to sharing credentials, the triple: [userDomain, userName,
userPassword].	i think stored challenge should be an implementation detail for
both the necko auth cache as well as the java auth cache.  with this API that i
am proposing, the java plugin can query the necko auth cache to see if it has
any stored auth credentials.  likewise, the java plugin can add new credentials
to the necko auth cache.

under the hood, the necko auth cache will need to be able to store a NULL/empty
challenge for auth credentials stored by via this new interface.  if a NULL
challenge is found in the necko auth cache, then necko should not try to send
an Authorization header until challenged by the server.  the same goes for the
java plugin.  i think this helps simplify the problem a great deal.

note also that this new interface takes NTLM into account.
my patch for bug 159015 makes heavy modifications to nsHttpAuthCache.  so,
please let me know if you are working on this bug.  thx!
It's great for the new interface to take NTLM into account. I think I can work
to implement the new nsIHttpAuthManager interface soon.
Louie: great, but please keep an eye on bug 159015.  thx!  (marking this bug as
being blocked by bug 159015.)
Depends on: 159015
Joshua: your latest patch seems to be making use of the old interface.  can you
please comment on the new interface I proposed?  Thank you.
Hi  Darin,

There are two interfaces:
1. The interface between JPI and OJI.
2. The interface between OJI and Necko.

If Necko 's interface (interface 2) has been frozen, I will modify my patch to
use your latest interface.

I think OJI's interface (interface 1) could be frozen. (according to our
discussion between Zhengyu and me).
Joshua: it has not been frozen, but i believe that it is the interface we will
want to freeze for mozilla 1.4.  i don't foresee any need to modify it; however,
you might find it difficult to implement in terms of the nsHttpAuthCache as it
exists today.  i have made modifications to the nsHttpAuthCache for bug 159015
that will make this interface trivial to implement.  FWIW i expect to land my
patch for bug 159015 by 1.4 alpha.
Attachment #115824 - Flags: review?(darin) → review-
Darin, can you give a look at this patch? I have 3 question marked "TODO".
Comment on attachment 117697 [details] [diff] [review]
prototype of implement of the new version of nsIHttpAuthManager

>Index: netwerk/protocol/http/public/nsIHttpAuthManager.idl

>+    void getCredentials(in ACString aHost,
>+    void setCredentials(in ACString aHost,

on second thought, getAuthIdentity and setAuthIdentity would be better names,
i think.  getCredentials conflicts a bit with nsHttpChannel::GetCredentials
and nsIHttpAuthenticator::generateCredentials.


>Index: netwerk/protocol/http/src/nsHttpAuthManager.cpp

>+ * The Initial Developer of the Original Code is Louie Zhao
>+ * <louie.zhao@sun.com>.  Portions created by the Initial Developer

typically, you would put your company here... you should double
check with someone at your company! ;-)


>+nsHttpAuthManager::nsHttpAuthManager()
>+{
>+  NS_INIT_ISUPPORTS();
>+}

NS_INIT_ISUPPORTS() is no longer needed.  you can delete this line.


>+nsresult nsHttpAuthManager::Init()
>+{
>+  mAuthCache = gHttpHandler->AuthCache();
>+  NS_ENSURE_TRUE(mAuthCache, NS_ERROR_FAILURE);
>+  return NS_OK;
>+}

this could crash if gHttpHandler has not been initialized yet.
you should do this instead:

  nsresult nsHttpAuthManager::Init()
  {
    if (!gHttpHandler) {
      nsresult rv;
      nsCOMPtr<nsIIOService> ios = do_GetIOService(&rv);
      if (NS_FAILED(rv)) return rv;

      nsCOMPtr<nsIProtocolHandler> handler;
      rv = ios->GetProtocolHandler("http", getter_AddRefs(handler));
      if (NS_FAILED(rv)) return rv;
    }
    mAuthCache = gHttpHandler->AuthCache();
    NS_ENSURE_TRUE(mAuthCache, NS_ERROR_FAILURE);
    return NS_OK;
  }


>+nsHttpAuthManager::~nsHttpAuthManager()
>+{
>+  mAuthCache = nsnull;
>+}

not necessary to null out mAuthCache here.  it is just extra code.


>+nsHttpAuthManager::GetCredentials(const nsACString & aHost,
...
>+  if (NS_FAILED(rv) || !entry)
>+    return rv;

    if (NS_FAILED(rv))
      return rv;
    if (!entry)
      return NS_ERROR_UNEXPECTED;


also, you should add this change to nsHttpChannel.cpp:

Index: nsHttpChannel.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v
retrieving revision 1.152
diff -u -r1.152 nsHttpChannel.cpp
--- nsHttpChannel.cpp	6 Mar 2003 05:42:35 -0000	1.152
+++ nsHttpChannel.cpp	19 Mar 2003 07:56:12 -0000
@@ -2035,11 +2035,12 @@
     if (NS_SUCCEEDED(rv)) {
	 nsXPIDLCString temp;
	 const char *creds = entry->Creds();
-	 if (!creds) {
+	 const char *challenge = entry->Challenge();
+	 if (!creds && challenge) {
	     nsCAutoString foo;
-	     rv = SelectChallenge(entry->Challenge(), foo,
getter_AddRefs(auth));
+	     rv = SelectChallenge(challenge, foo, getter_AddRefs(auth));
	     if (NS_SUCCEEDED(rv)) {
-		 rv = auth->GenerateCredentials(this, entry->Challenge(),
+		 rv = auth->GenerateCredentials(this, challenge,
						entry->User(), entry->Pass(),
						entry->MetaData(),
						getter_Copies(temp));

this patch will ensure that we don't crash if |entry->Challenge()|
is null.
In this patch, I have fixed all the issues posted by darin.
Attachment #115824 - Attachment is obsolete: true
Attachment #117705 - Flags: review?(darin)
need plugin/oji module owner 's review/super-review.
Attachment #117461 - Attachment is obsolete: true
Comment on attachment 117715 [details] [diff] [review]
The latest OJI 's patch to follow change of Necko interface

Patrick, 
Please super-review. Thanks a lot!
Attachment #117715 - Flags: review?(beard)
Comment on attachment 117705 [details] [diff] [review]
updated patch following darin's comments

r=darin
Attachment #117705 - Flags: review?(darin) → review+
Comment on attachment 117715 [details] [diff] [review]
The latest OJI 's patch to follow change of Necko interface

>Index: modules/oji/public/nsIJVMAuthTools.idl

>+[noscript, uuid(078a1b99-6be2-4a57-a749-378f4a506097)]
>+interface nsIAuthenticationInfo : nsISupports
>+{
>+   readonly attribute string  username;
>+   readonly attribute string  password;
>+};

how are you handling non-ASCII username and password?  does JPI
not support non-ASCII username and password?


>+[scriptable, uuid(82274a32-a196-42ee-8e3b-fcb73e339518)]
>+interface nsIJVMAuthTools : nsISupports {

all of the methods are non-scriptable... should this interface
also be non-scriptable?


>+%{C++
>+    NS_DEFINE_STATIC_CID_ACCESSOR(NS_JVMAUTHTOOLS_CID)
>+%}

this should not be necessary.


>Index: modules/oji/src/nsJVMAuthTools.cpp

>+NS_IMPL_AGGREGATED(nsJVMAuthTools);

does this object really need to support aggregation?

>+                                                ToNewCString(username),
>+                                                ToNewCString(password));

this is a lossy conversion from UCS-2 to US-ASCII.  is that really ok?


>+    nsCAutoString hostString(host);
>+    nsCAutoString pathString;
>+    nsCAutoString realmString(realm);
>+    nsAutoString domainString;

      nsDependentCString hostString(host);
      nsDependentCString realmString(realm);


>+    if (NS_FAILED(rv))
>+        return NS_ERROR_FAILURE;
>+    else
>+        return NS_OK;

else after return is meaningless.

      if (NS_FAILED(rv))
	  return NS_ERROR_FAILURE;  // why not |return rv;| ??

      return NS_OK;


>Index: modules/oji/src/nsJVMAuthTools.h

>+ * Version: NPL 1.1/GPL 2.0/LGPL 2.1

all new code should be written using the MPL tri-license.
Attachment #117705 - Flags: superreview?(bzbarsky)
Attachment #117705 - Flags: superreview?(bzbarsky)
Attachment #117705 - Flags: review?(antonio.xu)
Attachment #117705 - Flags: review+
All parts(need to modify) are modified except the following two:

1. NS_IMPL_AGGREGATED(nsJVMAuthTools);
   does this object really need to support aggregation?
All services in OJI keep this same style.

2. >+[noscript, uuid(078a1b99-6be2-4a57-a749-378f4a506097)]
>+interface nsIAuthenticationInfo : nsISupports
>+{
>+   readonly attribute string	username;
>+   readonly attribute string	password;
>+};
 how are you handling non-ASCII username and password?	does JPI
 not support non-ASCII username and password?

Can't export some String type (nsACString, nsAString and so on) to JPI side.
and char* store UTF8 string.
JPI side can transfer it to Unicode jchar*
would it be easier to use |PRUnichar*| instead of formating as UTF-8.  anyways,
if the data should be considered UTF-8, then you should not be using
AssignWithConversion, ToNewCString, etc.  you should be using
NS_ConvertUCS2toUTF8, NS_ConvertUTF8toUCS2, and ToNewUTF8String instead.
Comment on attachment 117705 [details] [diff] [review]
updated patch following darin's comments

sr=darin instead =)
Attachment #117705 - Flags: superreview+

        Attachment #117715 -
        Attachment is obsolete: true

    
  

        Attachment #117715 -
        Flags: review?(beard)

    
    

    
  
Comment on attachment 117820 [details] [diff] [review]
Update OJI patch for UTF-8 -> UCS2 convert

>Index: modules/oji/src/nsJVMAuthTools.cpp

>+    nsCAutoString      pathString;
...
>+    nsresult rv = authManager->GetAuthIdentity(hostString,
>+                                               port,
>+                                               realmString,
>+                                               pathString, 
>+                                               domainString,
>+                                               username,
>+                                               password);

one final comment: pathString is unused, so declaring nsCAutoString
is costly.  it reserves space on the stack for no reason.  use
nsCString instead.

      nsresult rv = authManager->GetAuthIdentity(hostString,
						 port,
						 realmString,
						 nsCString(),
						 ...


>+    nsCAutoString      pathString;
>+    nsDependentCString realmString(realm);
>+    nsAutoString       domainString;
>+    
>+    nsresult rv = authManager->SetAuthIdentity(hostString,
...
>+                                               pathString, 
>+                                               domainString,

same thing here for |pathString| and |domainString|.

sr=darin with that change.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        optimized patch
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 117824 [details] [diff] [review]
optimized patch

looks good.  requesting r= from peterl.

        Attachment #117824 -
        Flags: superreview+

        Attachment #117824 -
        Flags: review?(peterlubczynski)

    
    

    
  
Comment on attachment 117824 [details] [diff] [review]
optimized patch

r=peterl, looks good but I think you can loose the NS_INIT_ISUPPORTS()

        Attachment #117824 -
        Flags: review?(peterlubczynski) → review+

    
    

    
  
oh right.  NS_INIT_ISUPPORTS is not needed anymore.  thanks for catching that peter!

    
    

    
  
Comment on attachment 117705 [details] [diff] [review]
updated patch following darin's comments

looks good!

        Attachment #117705 -
        Flags: review?(antonio.xu) → review+

    
    

    
  
Comment on attachment 117824 [details] [diff] [review]
optimized patch

>+NS_METHOD

That should be NS_IMETHODIMP.

>+nsJVMAuthTools::AggregatedQueryInterface(const nsIID& aIID,
>+                                         void** aInstancePtr)
>+{
>+    if (aIID.Equals(kIJVMAUTHTOOLSIID)) {
>+        *aInstancePtr = this;

There should be an NS_STATIC_CAST to the appropriate interface here, even
though it probably doesn't matter right now.

>+        AddRef();
>+        return NS_OK;
>+    }
>+    
>+    if (aIID.Equals(kISupportsIID)) {
>+        *aInstancePtr = GetInner();
>+        NS_ADDREF((nsISupports*)*aInstancePtr);
>+        return NS_OK;
>+    }
>+    return NS_NOINTERFACE;

But why not use the appropriate macros instead:

NS_INTERFACE_MAP_BEGIN_AGGREGATED(nsJVMAuthTools)
  NS_INTERFACE_MAP_ENTRY(nsIJVMAuthTools)
  etc...

(I admit I don't understand exactly what the nsAgg.h macros are up to.)

    
    

    
  
check in 2 patches
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 117824 [details] [diff] [review]
optimized patch

+/* readonly attribute string username; */
+NS_IMETHODIMP nsAuthenticationInfoImp::GetUsername(char * *aUsername)
+{
+    *aUsername = mUserName;
+    return NS_OK;
+}
+
+/* readonly attribute string password; */
+NS_IMETHODIMP nsAuthenticationInfoImp::GetPassword(char * *aPassword)
+{
+    *aPassword = mPassWord;
+    return NS_OK;
+}

Both of these methods violate the XPCOM out-param memory owenership rules. You
can't return a pointer to internal char* data, you have to return a copy of the
string data and the caller *must* free it once the caller is done with it.

    
    

    
  
I'm going to reopen this bug to get the above issue fixed, but if you prefere to
file a new bug on this issue, feel free to close this and open a new bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
jst:

thank you for catching that!  joshua: the code should be modified like this:

NS_IMETHODIMP nsAuthenticationInfoImp::GetUsername(char * *aUsername)
{
    *aUsername = nsCRT::strdup(mUserName);
    return *aUsername ? NS_OK : NS_ERROR_OUT_OF_MEMORY;
}

    
    

    
  
here's an alternate solution:

Index: nsIJVMAuthTools.idl
===================================================================
RCS file: /cvsroot/mozilla/modules/oji/public/nsIJVMAuthTools.idl,v
retrieving revision 1.1
diff -u -r1.1 nsIJVMAuthTools.idl
--- nsIJVMAuthTools.idl 24 Mar 2003 06:25:02 -0000      1.1
+++ nsIJVMAuthTools.idl 26 Mar 2003 04:50:07 -0000
@@ -34,6 +34,7 @@

 %}

+[ptr] native const_char_ptr(const char);

 [noscript, uuid(078a1b99-6be2-4a57-a749-378f4a506097)]
 interface nsIAuthenticationInfo : nsISupports
@@ -42,8 +43,8 @@
     * AuthenticationInfo (username/password pair)
     */

-   readonly attribute string  username;
-   readonly attribute string  password;
+   readonly attribute const_char_ptr  username;
+   readonly attribute const_char_ptr  password;
 };

 [noscript, uuid(82274a32-a196-42ee-8e3b-fcb73e339518)]


with this interface change it becomes valid to return a simple reference to the
internal copy of the strings.

    
    

    
  
As long as the out param is const char **, not char **, right?

    
    

    
  
Comment on attachment 118525 [details] [diff] [review]
change out param from char ** to be const char **

sr=darin

        Attachment #118525 -
        Flags: superreview+

    
    

    
  
Comment on attachment 118525 [details] [diff] [review]
change out param from char ** to be const char **

Thanks!

        Attachment #118525 -
        Flags: review?(jst)

    
    

    
  
Comment on attachment 118525 [details] [diff] [review]
change out param from char ** to be const char **

I still think follow the XPCOM memory ownership rules here and just copying the
strings and make the caller free them would be the more right thing to do.
Apparently the reason for not doing that is that the JNI side that uses this
can't reliably free the memory that's allocated on the OJI side. Seems hard to
believe, but what do I know...

I can live with this approach, and there's presedence for doing things like
this in this code, so...

r=jst

        Attachment #118525 -
        Flags: review+

    
    

    
  
checked in -> fixed
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
If this is fixed, shouldn't it be removed from the relnotes? :)

    
    

    
  
Hallo,
I know this is a dumb question... but in which Mozilla version will the Java
auth problem be fixed ??

In Mozilla 1.4b this is still not working...

Bye
  Rainer Tammer

    
    

    
  
This bug need to be fixed on both mozilla and jre side.
We have fixed on mozilla side, you must wait the new jre (jpi).

    
    

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

    
    

    
  
What version of Mozilla has fixed it?  I still have the problem with Mozilla
1.4b and JDK 1.4.2-beta.

If I start Mozilla with http://gemal.dk/test/javajava.html, I get 4 prompts.

1. Prompt for my proxy server by the browser
2. Prompt for basic authentication at the site by the browser
3. Prompt for my proxy server by the java plug-in
4. Prompt for basic authentication at the site by the java plug-in

If I close any of the java plug-in dialog boxes without entering the correct
information, I never get the prompt again.  Even after hitting Shift+Refresh
which is supposed to reload the java applet.  The only option is to completely
exit from Mozilla.

Which brings me to another problem I have with Mozilla.  I can't open multiple
instances of Mozilla with different sessions.  All Mozilla windows opened either
from File->New->Navigator Window or by starting from the desktop share the same
instance.  If I start IE from the desktop I get another instance.  

So if I unintentionally close the java plug-in dialog and I have to use the
applet, I have to exit Mozilla by closing all open windows of Mozilla so I can
get a shot at the page with the applet again.  This may be a java plug-in bug,
but it still screws me up by forcing me to close Mozilla windows that I needed open.

Regards
Milind

    
    

    
  
see #144

    
    

    
  
I was refering to #144.

Has it been fixed in Mozilla 1.4b?

Is it known which version of the JRE will fix the problem?  I thought that 1.4.2
was supposed to have fixed it.  For some reason, I assumed that NTLM support
will also include this fix.  Guess I was mistaken.

Milind



        Attachment #118525 -
        Flags: review?(jst)

    
    

    
  
I'm not at Mozilla 1.5 and Java 1.4.2_02.

I too am interested in hearing any speculation on when this issue could be fixed?

    
    

    
  
this now work fine with Sun's JRE 1.5.0 beta 1 (tested Firefox 0.8 on Win2k).

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: