lock down COMMAND & Re-writing Help - Protocols

This is a discussion on lock down COMMAND & Re-writing Help - Protocols ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: lock down COMMAND & Re-writing Help

  1. lock down COMMAND & Re-writing Help

    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.

    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.


    ----------------------------------

    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.

    Any chance of allowing us to create windows like that?



  2. Re: lock down COMMAND & Re-writing Help

    On 2006-03-29, Scott Caissie 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

  3. 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" wrote in message
    news:slrne2o857.ikh.fdc@sesame.cc.columbia.edu...
    > On 2006-03-29, Scott Caissie 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




  4. Re: lock down COMMAND & Re-writing Help

    This behavior is working as designed. While executing a prompt
    in command mode the macro can accept input from the user. Therefore,
    keystrokes are queued in the command prompt queue. There is no
    mechanism to disable this functionality and there is no mechanism
    to clear the keyboard queue.

    Jeffrey Altman


    Scott Caissie wrote:
    > 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" wrote in message
    > news:slrne2o857.ikh.fdc@sesame.cc.columbia.edu...
    >> On 2006-03-29, Scott Caissie 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

    >
    >


+ Reply to Thread