Re: lock down COMMAND & Re-writing Help

As for the security one. Its not so much for actual security of danger or
misuse. Its just to protect the user from accidents. I'm familiar with those
commands. None of them actually prevent key strokes being sent to the
command window when a macro is invoked.
When an accident occurs, it generally doesn't effect that particular
macros/definitions, but rather the next one, and the rest, that gets
invoked.

You see, when this occurs, though its rare to happen, it disables my macros
(defintion ones) completely. That tiny fraction of a second, as the screen
goes to from the connect window to the command window, or as it from from
the command window to the connect window. I think it mostly occurs when the
user activates 2 different definition macros at once.

The only way to fix it IS by pressing Alt X which allows the sent keys to be
'cleared'. It'll say something along the lines of "SLJAFA is not a macro or
command.". After that, I can resume using macros. So I'm at a paradox on
that.

This is why I was adding ECHO, CLS, etc to the start of the macros in the
hope that it clears that.
Honestly I think my best bet is likely to re-write the some of my macros. I
found a way to make it less processor intensive so it would be faster.



"Frank da Cruz" <fdc@xxxxxxxxxxxx> wrote in message
news:slrne2o857.ikh.fdc@xxxxxxxxxxxxxxxxxxxxxxxxx
On 2006-03-29, Scott Caissie <scottac@xxxxxxxxxxxxxxx> wrote:
: 2 situations here.
:
: 1. Help with security here.
:
: I'm looking at a few things to secure the software a bit, which'll cause
the
: user to not accidently damage anything.
:
: Is there any way possible to prevent a user from typing anything in the
: COMMAND window? And I don't mean SET TERMINAL ESCAPE-CHARACTER DISABLED.
: That does prevent them from reaching the command window but regardless
of
: that, invoking macros (definition macros) will change the screen. During
: that fraction of a second of loading, it is possible for a user to type
: something and have it appear in the prompt. This will prevent a proper
: execution of the macro. Its rare but I want a way to fix that.
:
If they can get to the command window, they can use it. So the best thing
is to prevent them from getting to it.

SET TERMINAL ESCAPE-CHARACTER DISABLED ; Disables ^]c etc
SET KEY 2168 \Kignore ; Disables Alt-x
SET KEY 2136 \Kignore ; Disables Alt-X
SET COMMAND INTERRUPTION OFF ; Disables Ctrl-C

Then, to prevent use of the Tool Bar and Menu Bar for switching to the
Command screen, start K95G.EXE with the following command-line arguments:

--notoolbar --nomenubar

: I'm now adding a number of things at the very beginning of my macros
that
: might clear whatever is there:
: ECHO
: CLS
: probably going to put \13 (enter) there as well.
:
: But I do not know the order of how things are processed to know if it'll
: make a difference. I have some doubts that the macro itself can clear
the
: junk characters. I have a lot of doubt about preventing a user from
ever
: typing in the COMMAND window. Could be possible. Don't know how yet.
:
If the connection is made by a script, then even though the command window
is visible until the connection is complete, and interruption of the
script
is disabled SET COMMAND INTERRUPTION OFF, and return to the command screen
from the terminal screen is impossible, then the user should have no
opportunity to interact with the command prompt.

Of course if the connection is broken, then Kermit returns to the command
screen. Therefore your script should contain an EXIT command immediately
after the CONNECT command.

: 2. The help window (Alt H). Can this be edited in any way? I'd like to
: modify it so that it has actual work info in it. We don't actually use
: hotkeys at all.
:
Sorry, no, you can't edit the popup help text. I was about to suggest
redefining the Alt-h key to pop up an ASK /GUI dialog containing the text
of your choice, but that would require assigning a macro to a keystroke,
which, as you know if you followed the recent discussion, does not
presently
work, and in any case there's not much room for text in the dialog box,
and
the text entry box would be confusing.

Customized help is something to be considered for a future release.

- Frank


.

Relevant Pages

  • Re: lock down COMMAND & Re-writing Help
    ... in command mode the macro can accept input from the user. ... keystrokes are queued in the command prompt queue. ... You see, when this occurs, though its rare to happen, it disables my macros ... goes to from the connect window to the command window, ...
    (comp.protocols.kermit.misc)
  • vi editor FAQ (Frequently Asked Question List), Part 2/2
    ... has the UCB distribution of vi, and lots of useful macros. ... m0 is the ex command to move the line to line 0. ... Swap character and one vertically above: ... A non-visual editor under Unix. ...
    (comp.unix.questions)
  • vi editor FAQ (Frequently Asked Question List), Part 2/2
    ... has the UCB distribution of vi, and lots of useful macros. ... m0 is the ex command to move the line to line 0. ... Swap character and one vertically above: ... A non-visual editor under Unix. ...
    (comp.unix.questions)
  • vi editor FAQ (Frequently Asked Question List), Part 2/2
    ... has the UCB distribution of vi, and lots of useful macros. ... m0 is the ex command to move the line to line 0. ... Swap character and one vertically above: ... A non-visual editor under Unix. ...
    (comp.unix.questions)
  • vi editor FAQ (Frequently Asked Question List), Part 2/2
    ... has the UCB distribution of vi, and lots of useful macros. ... m0 is the ex command to move the line to line 0. ... Swap character and one vertically above: ... A non-visual editor under Unix. ...
    (comp.unix.questions)