I was thinking of an idea for a game contest that let people write small javascript snippets inside of their browser to fill in logic for the non-boiler plate portions of the game code. Basically, the contest would provide a simple set of functions/framework for making simple, 2D games (probably puzzle games), and you would create an account on the site, get a small amount of storage for your scripts, could maybe even setup simple project pages, write a simple game using the on-site editor, and then save it to present to other people.

The problem I'm running in to is making sure that black-hat users don't upload code that messes with anything outside of the framework. Presumably, players might also have accounts on the site (maybe just for the fact that they are also game makers), and a particularly nefarious user could write scripts that would impersonate that user because the script would be running within the site domain, so it would get around XSS restrictions.

Any suggestions? I think I just need to somehow prevent direct access to anything in the DOM.

I was thinking of an idea for a game contest that let people write small javascript snippets inside of their browser to fill in logic for the non-boiler plate portions of the game code. Basically, the contest would provide a simple set of functions/framework for making simple, 2D games (probably puzzle games), and you would create an account on the site, get a small amount of storage for your scripts, could maybe even setup simple project pages, write a simple game using the on-site editor, and then save it to present to other people.

So you want to provide people with basically a javascript "game engine" and let them create games based on this javascript framework?

The problem I'm running in to is making sure that black-hat users don't upload code that messes with anything outside of the framework.

Javascript is like that. It's the C++ of the browser world.

Presumably, players might also have accounts on the site (maybe just for the fact that they are also game makers), and a particularly nefarious user could write scripts that would impersonate that user because the script would be running within the site domain, so it would get around XSS restrictions.

Register two domains. One is for creation and the other is for playing. jscreator.com and jsplayer.com would be separate the pools, so to speak, and keep your domain barriers where they need to be.

Any suggestions? I think I just need to somehow prevent direct access to anything in the DOM.

Then you don't want to use javascript. You'd have to write your own superset of javascript like the jQuery team did and then you'd have to strip out any native javascript usage and only allow your own proprietary structure. You could strip out certain calls like "document.getElementById" but that is pretty laborious as there are several ways to achieve the same effect.

Is this server-side JavaScript? If it is, then check out the latest issue (June 2011) of JsMag. My article on Game Development using Node.js in this month's issue talks about adding scripting language support to the game engine as well as sandboxing it.

You can use the coupon code neb9v6k for a free issue.

So you want to provide people with basically a javascript "game engine" and let them create games based on this javascript framework?

Yeah, like I said, it'd be really simple things. I'm thinking of this as an educational tool that I can use to teach classes on programming at my hackerspace.

Register two domains. One is for creation and the other is for playing. jscreator.com and jsplayer.com would be separate the pools, so to speak, and keep your domain barriers where they need to be.

That solves the one issue of protecting the user's account from the games, and is definitely a good suggestion.

Then you don't want to use javascript. You'd have to write your own superset of javascript like the jQuery team did and then you'd have to strip out any native javascript usage and only allow your own proprietary structure. You could strip out certain calls like "document.getElementById" but that is pretty laborious as there are several ways to achieve the same effect.

Yeah, I had considered doing that and was kind of hoping I wouldn't have to.

I might check out some of the projects for converting Python to JavaScript and run from there. Python would be a little more conducive to my purpose anyway.

Is this server-side JavaScript? If it is, then check out the latest issue (June 2011) of JsMag. My article on Game Development using Node.js in this month's issue talks about adding scripting language support to the game engine as well as sandboxing it.

no, definitely client-side.

So you are allowing users to add code for when certain events or actions happen, right? That means someone could submit an infinite loop, which would cause an individual browser to grind down, right?

When dealing with user submitted code, especially those running on the client, there is little you can do to limit the JS execution.

If you are interested, what you can do is build a framework in which the client API is a proxy layer to a message-based server.

The server can be a JavaScript based server that can properly sandbox the user submitted code.

That's your best option, IMO.

There is one other thing that can help you. ECMAScript 5 compliant browsers also allow you to freeze and seal objects. ECMAScript I the standard that JavaScript follows.

Might be useful to you.