[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev ftp://user:address@hidden too much unencripted info
From: |
Klaus Weide |
Subject: |
Re: lynx-dev ftp://user:address@hidden too much unencripted info |
Date: |
Mon, 8 Nov 1999 17:12:34 -0600 (CST) |
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
lynx-dev Suggestion for merging the libcurses and libslang code, vtailor, 1999/11/08
Re: lynx-dev Suggestion for merging the libcurses and libslang code, Klaus Weide, 1999/11/08