Re: [platform-update-dev] plugin proposal for the problem of proxy conne

[<laurent@xxxxxxxxxxxxxxx>]

After studying a little the webdav authentication source, I saw they don't rely on the standard java mechanism for authentication. Instead, they define an authenticator for use in HttpClient.java. And they redevelop completely the dialog between client and server. It is obviously much more complicated that my present solution which rely heavily on the standard java mechanism for proxy access, but is completelty transparent for the plugin developer.
If we ignore presently authentication in my solution, it become only a sympathetic GUI for setting some system properties, which could be set by startup arguments to the VM. (see http://java.sun.com/j2se/1.4/docs/guide/net/properties.html).
I'd appreciate some feedback on the way to go now:
- removing completely authentication from the plugin, 
or
- developping a password manager much more evolved, without breaking webdav (if possible)
In case the second solution seems the preferred one, one could envision to propose the service of password management to all other plugin, including webdav (even if I don't know yet how to do that elegantly)

Laurent

> From:  <laurent@xxxxxxxxxxxxxxx>
> Subject: Re: [platform-update-dev] plugin proposal for the problem of proxy connections
> Date: Mon, 15 Jul 2002 15:48 -0500
> 
> 
> > I was just wondering if we should not drop the authentication from the
> > preference page as
> > 
> > 1) we do not encrypt the password
> > 2) we do not have a 'real' authenticator framework for now on, (i.e the
> > fist authenticator registered is the one) which means that if I try to
> > connect to a password protected site, the net access authenticator will be
> > used instead of the update/manager one...
> > 
> > What about just prompting the user all the time first ? and then we will
> > evolve it ?
> > org.eclipse.webdav apparently has a much more sophisticated
> > authentication...
> > 
> > second discussion point,  we should probably check the userid/password
> > against the realm instead of the protocol only, no ?
> > 
> > Chris
> I agree with the second point. In fact, an evolution I envision is to add the possibility to have a password manager like browsers, except better. In order to do that, the authenticator needs obviously to check again many more possibilities than just the protocol. 
> Now, for the removing of the authentication information from the plugin, I feel it could be proposed to the user, if he feel confident about the security of his system.
> An aside note: the first default authenticator is the one, in 1.3. In 1.4, it is no longer true (which explain my comment in the test section of html/index.html).
> Before I have time to remove/adapt authentification informations, testers can just say they don't use authentification, and then, the jdk should ask them the user/password to use, without storing it.
> As for encripting the password on disk, I'm interested to ear about a method working bidirectionnally in open source ;). Perhaps a main password protecting all the others?
> 
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-update-dev