When browse a page contains applet through a password protected proxy server, "Enter Network Password" dialog box appears twice.

The first time, proxy server challenge browser for username/password, this is desired behavior. However, if the requested page contains applet, subsequence download of applet classes caused "Enter Network Password" dialog box pop up from Java plugin side again. The second pop up can be avoided by abtaining Proxy-Authentication header from browser, and add this header for subsequence HTTP request.

  xxxxx@xxxxx   2001-10-23


  xxxxx@xxxxx   2002-04-15

Customer Problem Description;
-----------------------------

We have an applet deployed on a weblogic 6.1 server.  Our client is using the 1.3.1 plug in.  Our applet has many jar files.
For the most part everything works.  Since we have many different property files and support for 9 languages, we use the java.util.ResourceBundle class to manage loading these files.
The property files are located IN the jar files.  We only specify the language, so the names look like ... Emulator_de.properties, Emulator_en.properties, etc.

The resource bundle has a private method called calculateBundleNames.  This method defines the list of names the class will look for while trying to load the file.
This makes sense, since it is supposed to go from specific to general.
Problem:
Each time the resourcebundle tries to load a file that is not found in the jars ( Emulator_de_US.properties) it tries to go back to the server and look for the property file.
Now each time it wants to go past our proxy server and through the firewall, java asks for our name and password.
Our product works fine as long as we type in our name and password around 50 times.

Why can it not remember the username and password?  I believe this is because it is opening a new connection each time.

We would like some way of getting around this.

We would also like to reduce traffic.  If I have 20,000 people logging in each day, that are each making 50 unnecessary hits looking for classes ....
we are talking about 20,000 x 50 = 1,000,000 unnecessary requests to the server.

TESTCASEBEGIN
Create an applet with many properties files.
Make sure there is a proxy server / firewall in between the client and the server.
Try to use resource bundle to read the properties files from the jars.

This should prompt you for you name and password for each time it looks back at the server.




TESTCASEEND

N/A

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.

  xxxxx@xxxxx   2001-10-30

Could not reproduce what described by   xxxxx@xxxxx  . On Java side, there is only one authentication request for all the calls back to server through the same firewall.

  xxxxx@xxxxx   2002-04-16

It has been fixed for IE, a new REF will be open for Netscape.

  xxxxx@xxxxx   2002-07-26


If users are still getting prompted for authentication twice in releases where this bug has been fixed, please make sure that the box for "Save this password in your password list" has been checked on the first login prompt, and also that the fully qualified hostname is being used in the URL.

  xxxxx@xxxxx   2003-10-14

Why doesn't the plugin also store the information after the 
first time.  That would at least cut the authentication pop-
ups down to 2 instead of one per applet on the page.

If the JRE allowed the user to store the username and
password on disk, there could be only one popup each time
the JRE starts, and the user would merely have to press
Enter or click the OK button. This is how both IE and
Netscape deal with authenticating proxies.

I have this problem now since installing jdk1.4. I didn't 
have it previously.

Please let me know the detail method how to avoid the 
additional pop up requiring user authentication.

Please let me know the detail method how to avoid the 
additional pop up requiring user authentication.

I could not get even my jar files downloaded to client 
through the proxy server in j2re1.4.0. 

Bug #4656979 which has been closed as a duplicate of this, 
reported a problem in 1.4 that did NOT occur in 1.3.1.
How then can this be a RFE ???

I totally agree with Objects, as reported in Bug #4656979 
this broke my applet that is working in 1.3.1, this should 
be a bug. I am furthermore not convinced they are really 
the same bug, since I do not experience the problems of bug 
#4518282 and are not using any proxy server.

This is easy to reproduce.  Install Apache (I'm using 
1.3.23), create a simple hello world applet, add it to an 
equally simple HTML page, create a Alias in Apache's conf 
file to the html page and set up a Basic authentication 
file.

Start I/E or Netscape and http to your html file.  You will 
get two password dialogs.  Very annoying.

I believe that I may be experiencing something along these lines with WebStart. When an application is first 
downloaded, the cert requests authorisation from the user. If given, the app runs fine. However, the second 
time the app is run (already downloaded), the app fails due to a ClassNotFoundException (patently untrue 
as it wouldn't have been able to run the first time). I can't tell exactly what is going wrong  but it seems to 
be related. I must also agree with Objects as I do not experience the problems of bug #4518282 nor am I 
using a proxy server.

Our customers DO NOT understand this behavior, consider it 
truly stupid and inconsiderate of their time, and get very 
upset by it overall.  They blame us, not Java -- which is 
correct only in that we selected Java.

Realistically Sun's JPI MUST share HTTP and HTTPS 
authentication information with the browser.  It is up to 
them.  If MSIE won't give an appropriate API (really? MS APIs 
always seem to have a back door), then at least get one into 
Mozilla and use it!

I opened an RFE for this, but it was not accepted on the 
basis that is too similar to other bugs, so here you go:

There are several problems with network access in the Java
Plug-in.

- Users of sites that require authentication must log in
twice (3-4 times in some cases). Once for the web site and
another time for applets, compounded if a user uses a proxy
server that requires authentication. (see bugs 4166888,
4518282).

- No support for MS Proxy server, a very commonly used
proxy server (see bug 4423881)


Our solution to the first problem is to use a cookie that
is set when the user accesses the web site to authenticate
applet access; however this does not work when the user is
using a proxy server that requires authentication. Our
solution to the second problem (and for users behind
authenticating proxy servers) has always been to require
the users to use to access the applet and to make requests
from the applet using SSL. The result of this was that all
communication was routed through the user?s browser, which
can easily authenticate the user; however, in Java 1.4,
this capability was removed, since now, SSL communication
is handled entirely by Java. This makes 1.4 unusable for
real world applications, and we are forced to keep most of
our users on 1.3.1.

It seems to me that the obvious solution to these problems
is to allow an option to use the browsers? communications
APIs for communication. I realize that this will limit the
flexibility of URLConnection in that context, but I am more
than willing to live with those limitations if it means
that these problems will be solved. I believe that the old
BrowserHttpsURLConnection code could probably be reused to
implement this quite easily.

Preferably, this option should be specifiable as an applet
parameter. Including it solely as an option in the plug-in
control panel would not be the best solution, since it is a
logistical nightmare to walk end users through setting
options there.

P.S.  This is not specific to proxy authentication.

The issue is that the JPI does not share the browser's HTTP 
authentication cache.  This means that even when the you've 
authenticated for a JSP page or some such with the same 
realm, you have to do so again from your applets!

With JPI 1.3, you can use HTTPS as a workaround.   With JPI 
1.4, there apparently is no workaround!!!

I second twoodruff's comments.  Our customers will not put
up with going to a double login for JRE 1.4.  Currently,
when I get a customer using Win XP, I ask that they install
JRE 1.3 as that's the only way we can avoid this double
login problem.  Our customers don't care that Sun and M$
would love to see the other die a painful death, they just
want to only login once to our service.  Please Sun, don't
ditch all your  developers using SSL, basic authentication,
and applets!

Is this why the applets embedded with the <APPLET> tags on 
pages protected by HTTPS/SSL and Basic Auth require two 
Basic Auth logins using IE6 on my WinXP Pro machine? Very 
anonying!

I reverted to JRE 1.3.1 and the "double" auth nightmare 
stopped. 1.4 is seriously broken. No one will put up with the 
double login. No one.

What's the ETA on this fix going public?

I'm now using IE 6.0 and JRE 1.4.1, I still have to 
authenticate twice. Worse, if the web page opens another 
window that is big enough to hide the user/password box, 
when I close the popup window I can't see the user/password 
box anymore! The web page from which it originated is locked 
(which is expected, its waiting for the authentication), but I 
have to press ALT-TAB to switch between the opened 
applications until I find the user/password box !!!

I'm still seeing the problem using version 1.4.1_01 of the plug-
in and IE6.  This bug appears to have re-appeared in later 
releases (if it indeed was fixed in the first place).

I'm afraid that this Bug ID: 4518282 is not fixed in
1.4.1_02 or 1.4.0_03!

I tested this authentication issue with new JRE 1.4.1_02 and
IE 6 (in Windows XP sp1).
Result: Java Plug-in still prompts it's own "Password Needed
- Networking" dialog.
It should not prompt this extra dialog, because browser has
already done the authentication.

I also tested this issue with 1.4.0_03 + IE 6 (in Windows
2000), with same result.

All 1.3.x plug-ins works better: they don't prompt
username/password dialog (when applet is loaded by using
https:// -connection).

Actually, it works well if you allow IE to remember your 
password in its password list. So that's probably how Sun 
fixed the problem, by accessing this list. I'm not sure this is 
the best way to fix the problem, but it might have to do...

Ok, I take that back, it only worked with sites on our 
corporate Intranet ! I still get asked for a username/password 
for applets on the Internet. THIS BUG IS STILL THERE!

This bug is reproduced by IE6.0+Windows2000 SP4+JRE1.4.2. 
This problem is a fatal bug. This should be removed 
immediately. You should exhibit the environment, if it is said 
that this problem is corrected.

How can you say this is closed and fixed in 1.4.1_02 ?

Below shows the communications to get a secured html page 
with an applet. The headers have been stripped of irrelevant 
fields, but the GET's from java are shown in full.

Netscape getting html page:

===================================
GET /test/ HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-
US; rv:1.4) Gecko/20030624 Netscape/
===================================
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="Hello World", qop="auth", 
nonce="fe741a6a0f0e2684795cd8856b76d0a0", 
opaque="1b9b46e361ccbdba6ac9ccfd00589426"
===================================
GET /test/ HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-
US; rv:1.4) Gecko/20030624 Netscape/
Authorization: Digest username="Barry", realm="Hello World", 
nonce="fe741a6a0f0e2684795cd8856b76d0a0", uri="/test/", 
response="b17e6556497eb8687d72f62e4997206b", 
opaque="1b9b46e361ccbdba6ac9ccfd00589426", qop=auth, 
nc=00000001, cnonce="082c875dcb2ca740"
===================================

Java tries to get the applet - WITHOUT ANY 
AUTHENTICATION - gets a 401, and displays the login screen.

===================================
GET /test/applet.jar HTTP/1.1
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.4.1_02
Host: linux
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
===================================
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="Hello World", qop="auth", 
nonce="7aad5ecff9074b0ce27b35d06ed5223d", 
opaque="60adc182c48fee635417af5f1eb05a28"
===================================
GET /test/applet.jar HTTP/1.1
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.4.1_02
Host: linux
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Authorization: Digest username="Barry", realm="Hello World", 
nonce="7aad5ecff9074b0ce27b35d06ed5223d", 
uri="/test/applet.jar", 
response="767c94a8024146723de75fd3a7fa526f", 
algorithm="MD5", 
opaque="60adc182c48fee635417af5f1eb05a28", 
cnonce="JMDCEPEKNIJNANNGALFNHPAKDKCNABKEJDAKIHPB", 
nc="00000001", qop="auth"
===================================

It should also be noted that the plugin sends the nc value 
quoted (nc="00000001") which is contrary to the specs 
(RFC2617) and will fail on Tomcat.

There are no problems using IE with Microsoft's java.

I could not see any other bug relating specifically to 
Netscape as mentioned in the evaluation report.

I don't know who closed this bug but I still have this bug with 
newest version of the VM: 1.4.2-b28

Testcase:

Apache
protected Directory
Simple html-File that used an applet from the same directory
simple Hello-World applet
Browser calls html => RESULT: I get 2 logins

Problem still exists with Mozilla 1.4 and IE 6.0.

If I use the Microsoft VM (compiled the applet with -target 
1.1) I don't have the problem.

Also tried with Microsoft IIS as webserver and with same 
problem!

We have a Java product that will be released in a couple of 
weeks and we used some Swing components in jdk1.4. Please 
provide us a solution!!!

I installed the latest JRE and plug-in and I still encounter the 
problem. I have an applet in a secure environment. I log in 
successfully to the site, but the minute I bring the Applet up, 
it prompts me to log in again.

I would like to know an estimate on when this is going to be 
fixed since we need to deploy the applets with the Sun jdk 
since Microsoft is not supporting java anymore.

If you select "Remember the passowrd" in the browser login, 
the Java plug-in won't ask you to login again in JRE 1.4.1_02 
or later. 

Yes, This bug has not been fixed for 1.4.2. Now the question 
is who closed this bug? :( Anyway I don't think that we can 
ask our customers to set remember pwd. Obviousely this is 
not nice. However this is the one of the critcal issue I found 
so far in sun plugin. So pls reopen this bug.

Using v1.4.2_01-b06 does not fix this problem unless the 
option, 'Save this password', is selected. This solution is 
unacceptable primarily because that then creates a security 
vulnerability. If the Sun VM is installed on a computer where 
multiple people use a client under a shared logon, then other 
people could use someone elses credentials. Another 
fix/solution must be implemented.

I am seeing this on 1.5 as well.

Just downloaded the latest 1.5 jre and it still happens. (and there is no checkbox that says "save this password.."

The strange thing is that it doesnt happen with other users using the same browser and same jres.. is there a setting somewhere that I'm missing?

Hi, do you know where is located the password ????
thanks.

I've done a test with latest JRE in their respective version family, ie 1.3.1_20 & 1.4.2_16.  Well, the results depend on a lot of factors:

In IE6 & IE7:
* 1.3.1_20 is still broken in http but fixed in https
* 1.4.2_06 is fixed in http but semi-broken in https for IE6; still broken for both http and https for IE7
(semi-broken means that if the users select "save password", this is fixed: otherwise they're asked to input credentials again)

In FF2:
* 1.3.1_20: broken in http. No test for https has been done
* 1.4.2_16: broken for both http and https