[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] plugin proposal for the problem of proxy connections
|
My opinion is,
do #1 right first (+ other GUI stuff like, do not use proxy when this
address is used, (see netscape and ie options for instance, i lik enetscape
6.2 gui a lot)
Then we will polish it completely NLS, erro rlogging, testing etc so we can
deliver it for 2.0.1
After we deliver #1, then we can add the full authentication, password
management stuff. Update Manager may also have to provide a certificate
management etc...
So I would do a simple yet 100% complete #1
|---------+------------------------------------->
| | <laurent@xxxxxxxxxxxxxxx> |
| | Sent by: |
| | platform-update-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/16/2002 05:01 AM |
| | Please respond to |
| | platform-update-dev |
|---------+------------------------------------->
>----------------------------------------------------------------------------------------------------------------------+------------------------|
| | |
| To: platform-update-dev@xxxxxxxxxxx | |
| cc: | |
| Subject: Re: [platform-update-dev] plugin proposal for the problem of proxy connections | |
>----------------------------------------------------------------------------------------------------------------------+------------------------|
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
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
