Community
Participate
Working Groups
The Authenticator mechanism of java has not been designed with replaceability in mind (only one authenticator can be specified in the system, note that it can be replaced). Therefore people are fighting over the setting which sometimes results in failing authentication. In order to avoid this problem, I think eclipse should provide an extensibility mechanism around the authenticator.
*** Bug 22108 has been marked as a duplicate of this bug. ***
can you add more detail here about hte Authenticator? What is it? Where is it? what is it used for? how does it affect us or Eclipse developers/users?
To clarify, I'm talking about the java.net.Authenticator class. It is used to "represents an object that knows how to obtain authentication for a network connection. Usually, it will do this by prompting the user for information." (from the spec: http://java.sun.com/j2se/1.4.2/docs/api/). In the JRE itself, it is used by the implementation of http to get the user information when connecting to a secure server or when login information is requested. It affect eclipse because it is a singleton and various plug-ins fight over it, which cause authentication to fail if the wrong Authenticator is used (from the javadoc: Applications use this class by creating a subclass, and registering an instance of that subclass with the system with setDefault()).
This is similar to the singleton aspect of URLStreamHandlerFactory. In OSGi the URLStreamHandlerFactory is supported by a singleton object that proxies the calls to services registered with the framework. I know next to nothing about the Authenticator API but a quick look at the class indicates that a similar thing could be done. The approach would use a "white board" model. I would prefer to use an extension point vs the service registry to support something like this. Extensions could specify the protocol they support, or maybe some of the other arguments passed to requestPasswordAuthentication( InetAddress addr,int port,String protocol,String prompt,String scheme)
I think we looked at a similar approach based on realm. The issue will then be userid/password management ala Single Sign On then the other one will be: what is multiple people register the same realm The *easy* way is to force a UI/Headless Authenticator in eclipse. But then we will need to manage the uid/password somehow unless we want prompt the user *everytime* we get a 407
*** Bug 174129 has been marked as a duplicate of this bug. ***
The duplicate was raised as part of the bug to consolidate to a single preference page (bug 154100) for proxy settings. The platform should provide an authenticator which first checks the settings on the common preference page. If that fails it should consult any registered (via extension) authenticators to see if they will return a username/password. If not it should prompt the user via a dialog for a username and password which it should cache in memory. The Platform should also provide a persistance store for username/password with an API so that plug-ins can store username and password. These would be consulted by the platform authenticator. This would aviod having to load plug-ins which needed to provide authentication that they have already obtained.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
