Re: lynx-dev [PATCH]

[Klaus Weide]

On Fri, 23 Jun 2000, Vlad Harchev wrote:
> On Thu, 22 Jun 2000, Mike Castle wrote:
> > Also, let's say, instead of using the EXTERNAL command, the user wants to
> > use the standard built in lynx command occasionally.  What's the mechanism
> > for that?
> 
>   Seems there shouldn't be any (at least if using CERN rules). As for my
> patch, user can press 'x' and get original behaviour (since it's different
> command) but if development of original patch continues, that trick with
> 'x' command would have to be removed

No, it wouldn't "have to".  But maybe it's a good idea.
Invoke the EXTERNAL command, but tell it (with an environment variable?)
that this is a RELOAD request.  If the command is a lynx -dump or similar
(wget, ...), it can make use of that, for example by circumventing a
proxy cache that would normally be used.

> (so there won't be any way to get
> standard built in lynx functionality).

Here are two ideas to extend the EXTERNAL-based approach.

1. Don't make ACTIVATE run EXTERNAL commands.
Instead, make a new lynx key action ACTIVATE_OR_EXTERN (or
EXTERN_OR_ACTIVATE, if you prefer).  User can map Enter to
ACTIVATE_OR_EXTERN and leave Right Arrow mapped to ACTIVATE,
or the other way around.  So both built-in and EXTERNAL handling
can be available at the same time, without 'x' tricks.

2. Extend EXTERNAL as follows:
   instead of a boolean <allow_for_activate> flag, have a number
   0, 1...MAXSLOT.

   # EXTERNAL:<url>:<command> %s:<norestriction>:<allow_for_activate>

   becomes

   # EXTERNAL:<url>:<command> %s:<norestriction>:<slot>

   Make lynx key actions ACTIVATE_OR_EXTERN_1, ACTIVATE_OR_EXTERN_2 ...
   ACTIVATE_OR_EXTERN_<MAXSLOT>.  ACTIVATE_OR_EXTERN_1 runs only
   EXTERNAL commands configured with <slot>==1, a different key
   ACTIVATE_OR_EXTERN_2 runs only EXTERNAL commands configured with
   <slot>==2, and so on.  <slot>==0 (or omitted) acts as before, you
   need to press EXTERN ('.').


In any case, whether the abocve is used or not: As soon as Enter/Return
or an Enter/Return-like key can run EXTERNAL commands, *there should be
a mechanism for protection*.  Like the TRUSTED_EXEC mechanism, where
the decision of allowing execution depends not only on the command,
but also on various current settings (incl. 'O'ption Menu setting)
and on *the document including the link*.  One may accept running
an EXTERNAL command on links from some pages but not from others.
As long as a special EXTERN ('.') key was needed, it could be argued
that this wasn't necessary, because the user would be aware that he/she
was runnign an external command.  Not so any more if just Enter/Return
can do it.

IOW, something like the TRUSTED_EXEC / TRUSTED_LYNXCGI mechanism should
be applied to "auto-invoked" EXTERNAL commands, too.

  Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden