Re: lynx-dev [PATCH]

[Vlad Harchev]

On Fri, 7 Jul 2000, Klaus Weide wrote:

> 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.

 I already told about my attitude towards extending EXTERNAL. But anyway I
think that separating ACTIVATE and ACTIVATE_OR_EXTERN is a bad thing.

> 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 ('.').

  If functionality like this (binding several actions to one type of URL) is
desired, then IMO it's better to use plain EXTERNAL command and meta-wrapper
that will ask "press 1 for running blah, press 2 for running foo, press 3 for 
running baz". This is much more flexible and reasonable.

> 
> 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.

 I think efforts should be redirected to securing lynx{prog,exec} and to
allowing mailto: to be subject of CERN rules (using the patch you'll suply)
and to supporting external handler for mailto: urls. I think that CERN rules
should be primary mean for achieving
"ACTIVATE-and-all-other-commands-invoke-user-configured-handler-for-given-URL"
functionality.
  
 
>   Klaus
> 
> 
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
> 

 Best regards,
  -Vlad


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