Re: LYNX-DEV securing Lynx for boxed-in environments. (fwd)

[Foteos Macrides]

William Yang <address@hidden> wrote to me instead of lynx-dev:
>I'm pulling this off the list, because I don't think I'm communicating
>my environment's needs properly, at least to you.

        I'm pushing this back on the list because I doubt you are the
only one who would like it talked through to a full mutual understanding.
        

>Here's the sequence people go through on my system (which they've been
>doing for 3.5 years, and would react badly to changing).
>
>       1. User authenticates
>       2. User goes through a basic login sequence (terminal settings,
>          listing of sponsors, user agreement, and the like.
>       3. User gets an arrow-key navigable "main menu" which lists in a
>          user transparent way both content (Gopher/WWW/FTP/WAIS pages),
>          and tools (PINE, TIN, etc).  There is no difference for the
>          user, in terms of invoking PINE, TIN, or going to
>          http://www.somesite.com.  Everything looks like a link, as far
>          as the user is concerned.  This greatly reduces the amount of
>          tech support we have to do, because the interface is
>          completely integrated.  Presently, this is done with a
>          modified Gopher client, so there is only one mechanism for
>          going between services and content.
>
>As I understand the Jumps format from my reads of both userdefs.h and
>lynx.cfg, I lose the "everything is a link" user interface.  I can
>probably map a key to a service, or I can have users utilize a 'j'
>'mail' sequence... but, based on how the comments are worded, I don't
>appear to be able to make the first thing the users see be a "main menu"
>be the jumps page.

        Example jumps files for Unix or VMS are in the ./samples
subdirectory of the breakout.  Like bookmark files, they can be
viewed as a file://localhost/abs/path/foo.html text/html file,
and constitute a menu system which a user can navigate, like
any other text/html file, to ACTIVATE a, for example:

  <a href="lynxprog:/abs/path/tin">Invoke tin for news</a>

link as if it were an http://host/path link with link name
"Invoke tin for news".  If the user invokes the 'j'umps prompt,
a "?" entry displays that menu, and the user can navigate to
that link and ACTIVATE it.  The menu also indicates shortcut
names associated with each link in the menu, e.g., "tin" for the
above link.  Once a user learns those, he/she can use "tin"
instead of "?" at the 'j'umps prompt, and avoid the bother of
having to navigate through the menu to a link.  Also, if the
user learns the 'j'umps command, it can be used at any time,
e.g., to access tin, and on quiting from tin, the current
document and link will be restored, rather than having to
navigate [back] to an ordinary text/html menu file, and lose
one's place in the current document (although an experienced
user could use the history menu to avoid that; also see below).
Finally, if you use a jumps file, then any lynxexec and lynxprog
URLs in it are permitted by default, whereas if you use an ordinary
text/html menu file, and what to restrict what programs/scripts
can be accessed via lynxexec or lynxprog URLs, you must make a
series of:

        TRUSTED_EXEC:file/localhost/<tab>/abs/path/prog_or_script

entries in lynx.cfg for those permitted programs/scripts.  In
either case, it does still seem to me that what you want is
already available in Lynx.  The 'j'umps file menu, and associated
shorcuts, can be used for any URL, with any supported scheme (http,
https, telnet, tn3270, rlogin, gopher, file, ftp, wais, news, nntp,
snews, newspost, newsreply, snewspost, snewsreply, mailto, finger,
cso, lynxexec, lynxprog, lynxcgi).


>Thus, the part of the interface my users have gotten used to --
>namely, follow the link and it magically becomes a service -- really
>seems to require that I *not* run out of the Jumps file (because of
>the need for backward compatibility to previous interfaces).

        I hope I understand this paragraph, and that my preceding
paragraph gets across that exactly the opposite is the case.  Also
see below.


>Given the lukewarm interest that's been expressed by yourself and
>several other key individuals working on the Lynx effort, I'll
>probably end up writing a PERL script to automatically insert the
>appropriate header file when necessary to source files within the Lynx
>tree, and change the names of all calls to system(), execl(), execv(),
>execve(), execlp(), execvp(), and popen() to the internal names.  That
>way, I can leave LynxExec: and LynxProg: slightly more open, but will
>have the risk reduction I'm interested in, by containing what programs
>can be specified in those links.  That way, the need for portability
>and sustained supportability of the code will be maintained, without
>requiring any effort on the part of the folks on Lynx-Dev.  It's a
>slightly more involved solution on my side, but it's not unreasonable.

        It's not an issue of lukewarm interest, but concern that
you are seeking to reinvent wheels which already are there in Lynx.

        Note that the ./samples/jumpsUnix.html example in the
distribution is based on that used by the Chebucto freenet.
Also note that during a transition from a gopher to Lynx based
system, you can create a menu.html "main menu" page (with your
permitted lynxexec and lynxprog URLs specified via TRUSTED_EXEC
entries, as well as a 'j'umps file homologous to your ordinary
menu page), and an orientation.html page (which includes a link
to your menu.html and briefly orients your userbase to the changes
in your freenet service), and invoke Lynx via an alias that includes
-startfile=file://localhost/abs/path/orientation.html  and
-homepage=file://localhost/abs/path/menu.html          among its
switches.  The user can, at any time, use the 'm'ain menu command
(same letter as for gopher :) to invoke the menu.html menu.  If
you do not include a -homepage=URL, then the 'm'ain menu command
invokes the startfile., which after the transition can be made
your menu.html, with a link to an orientation.html in that.

        Finally, you can use the "launch file trick" to invoke
programs with any arguments and switches, and without need to
use lynxprog URLs.  For example, if your lynx.cfg has:

SUFFIX:launch.tin:application/x-tin
SUFFIX:launch.pine:application/x-pine
VIEWER:application/x-tin:/abs/path/tin[whatever] [-switches]
VIEWER:application/x-pine:/abs/path/pine [-switches]

and you create "dummy" /abs/path/launch.tin and /abs/path/launch.pine
files (which contain anything, e.g., "This is a launch file for tin."
and "This is a launch file for pine."), then the links:

  <a href="file://localhost/abs/path/launch.tin">Invoke tin for news</a>
  <a href="file://localhost/abs/path/launch.pine">Invoke pine for mail</a>

whenever and wherever ACTIVATEd will invoke tin with [whatever] [-switches]
or pine with [-switches].

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;