Re: lynx-dev [PATCH]

[Vlad Harchev]

On Sun, 9 Jul 2000, Klaus Weide wrote:

> On Sat, 8 Jul 2000, Vlad Harchev wrote:
> 
> > 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?
> 
> > > > (so there won't be any way to get
> > > > standard built in lynx functionality).
> 
> I still don't think that's good.
> 
> > > 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
> 
> >  I already told about my attitude towards extending EXTERNAL.
> 
> But you didn't really tell why, or did I miss it?

  The reasons: 
1) this is duplication of already existing functionality (CERN rules) 
2) If support for it for all cases is needed (not only interception of
        ACTIVATE command) then it's very hard to hack the code properly in all
        cases (there can be one - in getfile() - but this starts looking like 
        duplication of CERN rules functionality again)

> > But anyway I
> > think that separating ACTIVATE and ACTIVATE_OR_EXTERN is a bad thing.
> 
> Again, why?
> 
> It gives more choice to the user.

  Due to the reason#2, provided total interception is performed, the ACTIVATE
and ACTIVATE_OR_EXTERN will do the same in all cases.
 
> > > 2. Extend EXTERNAL as follows:
> 
> > >    # EXTERNAL:<url>:<command> %s:<norestriction>:<allow_for_activate>
> 
> >   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.
> 
> Sure, you can do that; I have actually made such a script for myself
> (but don't use it often anyway).
> 
> I just think the above would be a logica extension that doesn't require
> much extra effort or code, *if* you were to extend the EXTERNAL mechanism
> anyway.

   Now I begin to think that exactly 2 slots (primary + the one popping
menu of all choices) is a good idea. More than 2 slots makes no sense to me (I
think user will be unable to remember everything).
   
> > > 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
> 
> > > 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. 
> 
> Securing lynx{prog,exec}: good luck.  Are you going to do it?

  May be.

> The kind of people for whom this mechanism was primarily intended, and who
> invented and extended it, have all left the building (read: are not active
> on the list any more).  It's fairly hard to understand how even the existing
> protections are supposed to be used and how they work together.

  Have you read the branch for LYNXPROG_URL_TYPE and LYNXEXEC_URL_TYPE? It's
trivial. As for protection - I'm starting to think that quoting every special
character with backslash and using system() (there is no need to enclose
arguments into single or double quotes) will be very (if not most) reliable
solution. It really works - try it yourself, at least with bash. Probably 
POSIX should be consulted for whether it works on any UNIX.
  What do you think?

> Supporting external handler for mailto: urls:  In order to provide (at least)
> the same functionality as lynx's built-in handler, the interface for hooking
> in an external mailto-handler will have to be mailto-specific.  No generic
> mechanism will do.

  Of course it should be mailto: specific (in ideal world it may be wise to
think about news: too - but let's not).
 
> > I think that CERN rules
> > should be primary mean for achieving
> > "ACTIVATE-and-all-other-commands-invoke-user-configured-handler-for-given-URL"
> > functionality.
> 
> Maybe, but achieving
> "ACTIVATE-and-all-other-commands-invoke-user-configured-handler-for-given-URL"
> functionality was not what the request for an external mailto-handling command
> was about.  It was about "ACTIVATE-invokes-user-configured-handler-for-given-
> mailto-URL".

  We should thinkin more generic ways.
   
>    Klaus
> 
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
> 

 Best regards,
  -Vlad


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