Code/Object Security

[Hexagon]

I've been spending a lot of time scotchguarding the code I've been writing, which I find satisfying mostly because it helps me verify my logic in big nested blocks of code. When I say scotchguarding, I mean protecting it from an accident and not actually securing it against bad actors. For me, this is mostly checks and locks to make sure that player inputs don't clash with each other. If you're a dragonborn, you shouldn't be able to take the hill dwarf subrace.

I have been taking some forms of input and passing it through secure() or escape() or flagging certain attributes as NO_EVAL. It strikes me that this is probably something I should always be doing, and yet that also feels like overkill so I've been only using it when interacting with objects that are INHERITing some sort of elevated permissions.

Now, I'm looking at a very cool feature request that would like the ability to let an object act like a weapon and actually interract with the character sheet and roller. Mostly because they saw a softcoded version and really liked it, but they want to use the weapon as an object. They'd like to put a sweet desc on it, for instance. I like the idea because they can pass that magic item around and there is no ambiguity as to who has the object, and because I can dump them into a treasure chest and they can open it like a gift.

This is probably fine for the 4 or 5 people I run a D&D game for. This will not scale well if the code goes public, because I instantly see counterfeitting becoming an issue.

What steps do you take to secure your code and objects, and why? I'm coming at this from a MUX perspective, but I'm curious about everyone's practices.

[ZekeTheG33k]

There are a couple of ways to do this.

• Create the object as a wiz-owned object, set it no_command, lock it down with use etc. Then have your +set command acknowledge that children of a certain parent object can be set as well as players. Set your stats. Then on the player's stat storage store the DBREF of the object, and have your stat pulling functions look at items on that list when pulling the stats together.

• Option two is pretty much the same thing, but let the player create the object. Set it a specific parent when approved and add the DBREF to the list stored on their attributes. In this case, which it is already probably done, lock down the attributes globally that stats are stored on, to prevent twinkage.

• You could take the time to code a virtual object system, which defeats your general overall question, but you could put in trade commands and such to allow them to pass around the attribute cluster between players. Or store the data on a global database and create an item identifier and use it like the DBREF above.

That's just my two cents on the options that I would probably take to resolve.

[Hexagon]

@Seamus They currently have access to virtual objects, which is fun, but I get what they want. I was looking at doing something like the first so I'm glad to see I'm not the only one who thinks that would be feasable. I would probably actually build a "forge" command that would just straight up make the item according to spec.

Still curious about what other people do to secure their code and objects from accidents and bad actors.