Re: tls-ftp and GConf
- From: Alexander Larsson <alexl redhat com>
- To: Andy Hanton <andyhanton comcast net>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>
- Subject: Re: tls-ftp and GConf
- Date: 10 Sep 2003 10:11:23 +0200
On Tue, 2003-09-09 at 18:41, Andy Hanton wrote:
> On Mon, 2003-09-08 at 07:15, Alexander Larsson wrote:
> > Since vfs modules are very hidden, very "automatic" pieces of code, with
> > no user interface or visible user-model these kinds of settings just
> > don't work that well. Unless they are really honest-to-god preferences,
> > ie. do you prefer it this way or that way, everything still works
> > whatever you decide.
>
> I think that they should have a ui. No sane person is going to connect
> to an ftp server over ssl by typing ftp://user:password somesite com/
> into the location bar. They will use a password prompt dialog instead.
> On MacOS X there is an options button in that dialog that pops up a
> dialog with checkboxes for things like tunneling over ssh and allowing
> cleartext passwords. Those settings can be changed for the current
> connection or saved. It also has a button for changing the password. I
> think that this setting would fit in perfectly in a dialog like this.
> Of course this would require gnome-vfs or some other library to provide
> the dialog instead of forcing each application to handle the
> authentication callback and provide their own dialog, but I think this
> is required for decent handling of the differences between protocols.
> For example, the smb password dialog really should include a separate
> text box for the domain. I would assume that in the future some
> protocol will support certificates and only a passkey would be
> required.
>
> The Appletalk options dialog
> http://home.comcast.net/~andyhanton/temp/osx-afp-options.png
>
> The password dialogs from OS X
> http://home.comcast.net/~andyhanton/temp/osx-afp.png
> http://home.comcast.net/~andyhanton/temp/osx-smb.png
>
> I think apple has not done a good job keeping the dialogs consistent,
> but it does show the usefulness of allowing each protocol to at least
> add widgets to the authentication dialog.
These look like good ideas, however gnome-vfs modules just can't have a
UI, since the gnome-vfs library is conceptually at a lower level than
gtk+, and might even be used by console applications. We can't even rely
on a running glib mainloop in the gnome-vfs backends.
However, nobody is expected to enter password and username in the URL.
What happens is that the module that needs to do authentication does a
callback to the app and lets the app display the UI. Then if the app
uses libgnomeui, it can just call gnome_authentication_manager_init() to
install the default gnome handlers for the standard callbacks.
At the moment the standard status messages in
gnome-vfs-standard-callbacks.h are mostly http related, but one could
easily add ones that were ftp specific.
The way callbacks are set up at the moment will cause some small
problems when we go to a daemon-side implementation for some modules,
since they pass pointers and stuff, but that can be solved for standard
callback types by registering marshallers for them.
> > A better way of handling this problem could be trying to detect when the
> > firewall problem will happen, and reauth not using tls. I don't know how
> > feasible this is, but we should at least look into it. At the very least
> > if we chose to go with the gconf key route we need to handle timeouts in
> > the ftp method so that we don't hang forever. (This is also needed in
> > the http method btw. I looked at it once, and it didn't look that hard
> > to add. Wasn't in time for 2.4 though.)
>
> Silently falling back to cleartext sounded like a good idea at first,
> but is that what the user would want? If an advanced user knows that
> the site supports secure connections and that gnome supports them, they
> will expect to connect securely. I think that even less knowledgeable
> users would want to know if their password would be sent securely
> because they have become accustomed to it from the little lock icon in
> web browsers. It would be cool if we could have an icon in the lower
> left corner of the password dialog indicating whether the password would
> be encrypted or not. We could even steal the icon from epiphany.
At the moment all gnome-vfs password dialogs use
GnomeVFSModuleCallbackAuthenticationIn, which is very http-based. If you
pass AuthTypeBasic instead of AuthTypeDigest the default password dialog
will indeed warn you that the password is sent in plaintext.
> I am having difficulty thinking up a proper solution to the problem with
> firewalls that doesn't address these larger issues. I could pop up a
> dialog telling the user that the secure connection to the server failed
> and asking if the user wants to retry without tls, but this dialog could
> get really annoying for people behind firewalls. I could add a checkbox
> to the dialog for 'always use cleartext authentication for ftp', but
> then there would be no way for an end user to change their mind later
> unless the preference is added to the UI somewhere else. I agree that
> the timeout handler should prevent the application from hanging, but
> without some UI I don't see how it can do much more.
>
> Should I file RFEs for these ideas? Do you have any suggestions for how
> to fix this problem with firewalls in the short term? Do you think it is
> acceptable to fall back to cleartext authentication without telling the
> user?
We can work on the larger issues, since thats important. And since gnome
2.4 is basically out now we can start new development. However, i do
think that you can currently warn the user that authentication will be
in cleartext.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a fast talking soccer-playing vampire hunter She's a psychotic punk
vampire with a birthmark shaped like Liberty's torch. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]