[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17

From: Henry Nelson
Subject: Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17
Date: Wed, 22 Dec 1999 12:37:53 +0900 (JST)

> Now, postoptions() was only ever meant to be used from the Options Menu
> itself, according to all available evidence (comments and code).

Personally I would like to see it stay that way.  As you pointed out
in another post, even the original author of the forms-based Options Menu
had reservations about its security.  Reusing functions like postoptions()
elsewhere, eventually perhaps by totally unrelated operations, just seems
to be asking for trouble.

> [1] This is what the quoted CHANGES entry is about.  Note that this check
> is completely unspecific as to saving-to-.lynxrc or not.

Noted.  Thank you very much for clarifying that.

> [2] Whether the handler does save to .lynxrc depends on (a) whether
> it's allowed (option_save restriction) and (b) whether it's requested
> as part of the form submission.  Now, in this case the request, as it
> is generated by the V.Links mini-form, doesn't *ask* for saving, so no
> saving will happen for this reason.  Only the currently active state of

This, too, thanks.

> > Why can't, or why shouldn't we limit that to the forms-based Options Page
> > alone?
> We can; let the discussion continue if anyone's still listening...

Until I hear an argument the other way, I'd like to see that limitation
imposed -- or do more serious maintenance of the key-based O)ption Menu
as a "safe" alternative.

> > Did I make things any clearer?  I tried my best.
> Yes (although I still don't see how it would fit in that you seemed
> to prefer option-in-O.M.-only to option-in-lynx.cfg-and-O.M...).
No.  I MUCH prefer "option-in-lynx.cfg-only" to "option-in-lynx.cfg-and-O.M."
"option-in-O.M.-only" is unacceptable, IMO, and half of the reason I started
moaning in the first place.  In its submitted form it should never have been
integrated because of the obnoxious popup on the VLP itself and the way it
attempted to use a form-based OM function, also, IMO.  Sorry, but I still do
not understand why something like a tree-vs-list presentation needs to be on
the OM.


PS  No one should be influenced by my dislike of the popup on the VLP wrt
pages like the Cookie page.  The cookie stuff is a configure option, the
Page itself is optional.  The VLP, however, is a standard page and integral
part of Lynx.  Very different, IMO.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]