MOO-cows Mailing List Archive


Re: verb protection

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 !=
>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

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


Home | Subject Index | Thread Index