FTP inside mc

[Pavel Roskin]

On Fri, 19 Dec 2003, Thomas Kuiper wrote:

> Hello,
>
> I find the FTP interface of mc really useful and I'm willing to develop
> an extension to it to support FTP profiles. Right now its only possible
> to connect to a URL style address and its quite annoying to type or
> search/remember some frequently used FTP sites.

. From the hints:
Hint: Key frequently visited ftp sites in the hotlist: type C-\.

That should solve the problem with frequently visited sites.

> I'm thinking about a interface right now and thing it should be like
> this:
>
> Menu Left/Right->Ftp Link opens:
>
> ------------------ FTP Link -----------------
>   Profile Name:     ____________________[^]
>   Host:             ____________________
>   User Name:        ____________________
>   Password:         ____________________
>   Port:             22__________________
>   Init. Remote Dir: ____________________
>   Comment:          ____________________
>
>   [ ] Use passive transfer
>   [ ] Don't store password in profile
>
>   [< Ok >]  [ Cancel ]  [ Delete Profile ]
>
> ---------------------------------------------
>
> Rules:
>
> + If no Username was specified user "anonymous" is used (with password
>   configured under Options->"Virtual File System Settings".
> + Profile gets automatically saved when changed or name specified.
> + If the password isn't supposed to be stored in the profile its asked
>   in a new dialog.
> + Returns to the dialog in case a connection failed.
> +
>
> Suggestions?

I don't quite understand the idea of profiles and whether you are going to
use them for FTP connections only, or for fish and samba connections as
well.

Separate entries for host, username, password and remote directory -
should be OK.  Those who want to enter the complete URL can do it on the
command line.

"Comment" - I have no idea what it means.  Maybe you want to create an
alternative to the hotlist?  It was suggested many times, but every time
it turned out that the author of the idea wasn't aware of the hotlist.

I believe the hotlist has a visibility problem.  It's not noticed even by
those who need it.  Hints don't really help - most users ignore them.
Maybe if the "comment" field was used as the hotlist label and was labeled
"hotlist label" instead, more users would be aware of the hotlist.

"Use passive transfer" - good idea, but needs some work on the VFS side.
The hotlist works with directory names, which are plain strings.  It
doesn't save any hidden attributes, and rightly so.  There is currently no
way to specify FTP options in the VFS path.  There is support for options
in fish, which could be extended.

In fact, the general syntax of VFS path is undocumented.  There is no way
to use "@" in usernames, and there have been many complaints about it.

I think we should start with "pen and paper" and agree on the syntax of
VFS path, including options and ways to escape characters.  In case of
smbfs, there should be a way to put the workgroup in the URL, so that VFS
stops calling nontrivial user interface to request it.  Also, the
alternate path notations such as ftp://... and rsh://... should be agreed
on and documented.

Once we agree on the design, the functions for parsing the VFS path should
be fixed to implement the new standard.  After that we could write the
frontend that would create the VFS path in the new syntax and optionally
save the new path in the hotlist.

"Don't store password in profile" - I still don't understand the idea of
profiles.  If you agree on reusing the hotlist, we could think how to
implement this.

Maybe the password should be saved in .netrc, the standard place for all
FTP clients?  smbfs and fish would save passwords elsewhere, maybe in
~/.mc/fish_pass and ~/.mc/smbfs_pass respectively.

. From the user point of view, it would be great if the password was asked
for in the same dialog rather than separately, regardless of whether it's
saved.  But from the security standpoint, it's better not to have the
password as part of the VFS path. I tend to think that the user interface
should not allow creating a path with the password.  However, the
user:password syntax should be accepted if entered on the command line.

The existing code has some ad-hoc solutions for hiding the password from
the path, but I think it's not the best solution.  It's easy to forget to
strip the password.

To sum up, we should start with backend design before writing pretty
interfaces.

-- 
Regards,
Pavel Roskin