[EdwardSMaTeresa]

I'm making a html5 game that will allow the community to submit custom mods written in JS. Is it a bad idea? I'm thinking of sandboxing the modded code with node vm chatspin.download (clientside) or echat.date something.

[CrazY.]

It is not a bad idea if you design it correctly. I'm not really an expert on the subject but what I would do is expose some kind of api as amxmodx, that way you limit what the developers will have access to.

[EdwardSMaTeresa]

I think allowing users to submit raw code is a bad idea for two big reasons:

If the code is executed on the server, now your server is exposed.

If the code is distributed to the clients, now all your clients are exposed.

I think if you want mods, you have two paths, and both are going to be a lot of work:

Allow code, but it has to be white-listed. That means you or some other people need to go through each mod's code and ensure that it in no way could ever cause a problem on your server or for clients.

Find another way to process custom data. One great way is to design an action/response mechanism that could allow a modder to compose multiple pre-build actions. This constrains what they can do, but also means no one could write anything you, as the game developer, don't already allow. Think in terms of the Redux library, or the Elm language. A mod could be reduced to a json payload: { 'message-to-receive', [{ action: 'message-to-send', someVariableToPass: 'gameState.thing' }] }. With this mod, every time message-to-receive is send through your game event loop, it will generate a new message-to-send and pass any extra data with that payload, in this case, someVariabelToPass. This helps you not leak unnecessary data to the modder, and really restricts what a mod can do, especially not allowing a mod to call a method.