Re: lynx-dev ftp://user:address@hidden too much unencripted info

[Klaus Weide]

On Mon, 8 Nov 1999, Leonid Pauzner wrote:

> I mean:
> 
> (1) exclude password from URL in mainloop (or HTParse stage?) and keep
> it separately until the remote server responds with "enter a password",
> than send a password *automatically* on request.

Good luck trying.
My "fatalist" prediction is
 - It'll take a long time to find the right place(s) (your "or...?")
 - mainloop is way too late.  What about startfile, homepage, helpfile etc.
   referer, bookmarks, redirection statusline messages, LIST pages,...
 - You'll *take away* functionality if you do a passwordectomy on URLs,
   unless you always keep the passwords around in separate structures
   parallel to those structures that keep track of URL and combine them
   when that is needed.
 - You'll find that it's not worth the trouble to do it completely, so
   it will remain half-done.

If I *want to* enter URLs like "ftp://user1:address@hidden/"; and
"ftp://user2:address@hidden/";, and juggle between them in the same
session, I should be able to.  And both those URLs should be treated
as different from "ftp://address@hidden/";, because that's what they are.
I don't want a program trying to babysit me, just because someone thought
I need to be protected from myself to the degree that I can't go where I
want to.

> or better
> 
> (2) Change the samples in "URL Schemes Supported in Lynx" so they would
> appear without //user:passw@  but  //user@ with the explanation of yet
> another possibility added in words... So user will not get a wrong
> impression if reading that document not so carefully (you know, samples
> are so easy remembered without details). 

(2) is good.

> Anyway, non-interactive users
> could set password via command line flag.

Give them enough rope to hang themselves if they want.

There are risks involved with non-interactive scripts that contain
passwords, whether they use an ftp client, lynx, or something else.

   Klaus