Re: ftp and Nautilus

[Alexander Larsson <alexl redhat com>]

On Thu, 2004-05-20 at 16:24, Laszlo Kovacs wrote:
> Hi All,
> 
> Calum was kind enough to put together a proposal for going ahead.
> 
> It is all here:
> 
> http://www.gnome.org/~calum/usability/specs/ftp-login/
> 
> This needs changes in gnome-vfs (I have some of this code already) and 
> in gnome-keyring.
> 
> There are a couple of things to think about:
> 
> 1. With dialog2 we are proposing that the user will see the 
> authentication dialog coming back until they log in successfully or 
> press cancel. This is different from what we have now. Right now if the 
> authentication fails there is a warning dialog and that's it. The 
> proposal provides a better user experience. I am not sure yet where this 
> change needs to be made. It would be ideal if all vfs modules that 
> require authentication would nehave like this, but I think every module 
> would need to be changed separately for that.

Hmmm? This is not how it currently works, is it? We're currenly putting
up the auth dialog again until the user presses cancel. At least, thats
the intended behaviour.

> 2. We are also proposing to change the authentication dialog for the ftp 
> protocol only, for other protocols it will stay as it is.

Why are we doing that? That sounds wrong. We should do the same for all
protocols. (if they support anon/guest login)

> 3. If the uri contained a username the username field in the 
> authentication dialog (implemented in gnome-keyring) is not editable. I 
> think the reasoning behind this is that if the user wants a different 
> username or no username at all then they need to create a new launcher. 
> This is quite inflexible in general and creates a complication for this 
> situation as well. If we follow this thinking then if the user used 
> anonymous for the username in the uri then the tickbox should be ticked 
> in the dialog and the user should not be able to untick it. If we don't 
> do this then we don't have a consistent behaviour, however having a tick 
> box that can not be unticked is not good at all. Any suggestions 
> (particularly from the gnome-keyring maintainer) are welcome. I 
> personally think it might be good to make that username field always 
> editable again.

If the uri to be resolved contains a username we should never ever log
in as another user. This is guaranteed by never showing the username
entry in cases like this, instead we list the username in the label
above the entries. This is already implemented, try the http backend for
instance.

A backend should never ever pass the ASK_FOR_ANON flag (or whatever we
call it) to the auth callback if the uri contains a username. So the
problem you're describing should not happen.

Also, this is very very losely related to gnome-keyring, and requires
zero changes to gnome-keyring. Its all in gnome-vfs and libgnomeui.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an old-fashioned drug-addicted inventor looking for a cure to the poison 
coursing through his veins. She's a mistrustful Bolivian Hell's Angel married 
to the Mob. They fight crime!