# verb protection

Richard Godard (janus@cam.org)
Thu, 3 Oct 1996 06:00:03 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    At 0:24 -0500 10/3/96, James R O'Kane wrote:
    >I was thinking today during a boring calc recitation about ways to keep
    >people from over-riding verbs that i didn't want them to. and i came up
    >with 2 possiblilities..
    >
    >both involve adding props similar to the $server_options.protect_foo where
    >it's .protect_verbname.
    >
    >the first way would involve editing $add_verb and/or $bf_add_verb to
    >return E_PERM if .protect_verbname exists and is true and player !=
    >wizard.
    >
    >the second way is to have set_verb_code add a pass(@args) to the verb at
    >compile time, if it can't find it in the verb already..

    ... my_stuff ...
    raise(E_SECURITY_HOLE, "Verb overriden.") && 0 && pass(@args);

    >i see pros and cons to both ways.
    >pros to way 1: it gets the job done and seems to be the easiest.
    >cons to way 1: it stops people from making _any_ additions down the line
    >with out wizperms..even if they plan to use pass()
    >
    >pros to way 2: it allows people more freedom to add verbs as they choose
    >and pass(@args) is always called.
    >cons to way 2: it'll be a bit tick heavy to search for any pass()'s in the
    >verb and it kinda produces random results if programmers forget that
    >pass() is added.
    >
    >anyone have any thoughts on the matter?
    >i think this has come up before, but the list has grown quiet..:)

    I guess it depends what you plan to use the non-overridable verbs for as
    well as who will be allowed to make their verbs non-ovveridable.

    If you plan to use your verb for anything secure, #2 is NOT the way to go.

    I implemented non-overridable verbs for the masses (i.e. any proggie can
    make their verbs non-overridable if they needs to) Then I made :initialize
    non-overridable on $object (a parent of any objects that had #-1 as a
    parent (i.e. had no parent)) and then renamed non-wiz versions of
    :inititialize to :custom_initialize and made sure all (but the one on
    $object) the :initialize verbs pass(...)

    Now $bf_create call object:initialize() and then object:custom_initialize()

    That way I have a secure initialization (wiz ought to know what they code)
    and then programmers can initialize descendants of their generics through
    :custom_initialize without possibly interfering with the vital part of the
    initialization.

    Back to the original question:

    >cons to way 1: it stops people from making _any_ additions down the line
    >with out wizperms..even if they plan to use pass()

    If you make a verb non-overridable it's that you don't want it to be
    ovveriden, if you still want programmers to do some complementary work,
    call a custom non-blocked verb when you are done with calling your
    non-overridable verb.

    I hope this help.

    -- Richard