1 Project Description |
The goal of this RFE is to resolve multiple Proxy/Web Server authentication while running Java Applet.
Since Java Plug-in 1.4.0, Plug-in no longer relys on browser to provide networking capability, and implements all networking function by utilizing Java networking classes. The benefit of this approach is to eliminate browser depend code, have one code base to with all browsers. As a drawback of the approach, if the browser needs to go through a password protected proxy server, or run an applet on password protected web server, double authentication will result.
When browser try to load a HTML page that contains Applet through a password protected proxy server, or the HTML page is located on a password protected web server, browser will be challenged to authenticate against the proxy server or web server. Once the browser finished loading and start Java plug-in, plug-in will have to open its own connection through the proxy, or to the web server to fetch applet classes. Since the plugin has no knowledge of the result of browser's authentication result, it will be challenged to re-authenticate aginst the proxy server or web server again.
This is annoying side effect, since customers do not understand why they need to authenticate multiple time. The REF is filed to eliminate the second authentication from plugin side.
The problem exists on all Oss and browsers. But the REF only targets Internet Explorer and Netscape 7 or later.
NA
NA
2 Technical Description |
Internet Explorer:
Upon the success of chanellege, Internet Explorer will store the username/password along with the server/security realm that authenticate against in to its undocumented registery based storage, called protected store. Windows exposes the COM interfaces that allow applications to access the protected store. We take advantage of those interfaces, to get the username/password that stored in the protected store when plugin need to authenticate against the proxy/web server.
When ever plugin receives authentication request from networking code through PluginAuthenticator class, it asks BrowserService for BrowserAuthenticator. In this case, a WIExplorerBrowserAuthenticator will be returned, then it passes the server, authenication scheme and security realm information to the WIExplorerBrowserAuthenticator. WIExplorerBrowserAuthenticator then calls into native code to retrieve username/password pair by using "server/security realm" as key.
If the username/password pair is found, plugin will use them to re-authenticate against proxy/web server. But it is transparent to user, so user will not see the prompt for authenication. If the username/password pair is not found, the second authenication request dialog will be prompted.
Netscape 7 and later:
It depends on upcoming Netscape APIs.
3 Marketing |
4 Management and Planning |
Zhengyu Gu
Start Date |
End Date |
Activity |
Owner |
Status |
---|---|---|---|---|
07/08/02 |
|
|
|
|
|
|
|
|
|
Complete |
Started |
Not Started |
Difficulties |
Trouble |
Appendices (as needed, suggestions below) |
Bugid |
P |
S |
Subcategory |
Type |
Engineer |
Synopsis |
---|---|---|---|---|---|---|
|
|
|
|
|
|
|
Revision History |
Date |
Version |
Author |
Description |
---|---|---|---|
|
|
|
|