`Serve.Playground` should serve up a playground

[StartAutomating]

Module Playgrounds

A Module should be able to serve a playground, where code can be (somewhat) arbitrarily executed.

This should be safer than it sounds.

Like real playgrounds, Module playgrounds should be designed with safety first in mind.

Let's state the three simple safety principles of a playground.

1. Playgrounds are optional.
2. Playgrounds should be enclosed.
3. Playgrounds have rules!

Optional Playgrounds

If a module has a .Service(s) section that includes:

@{
    PlayGround = $true <# or a name #>
}

This will open the playground. Additional playground parameters would be described in the same table.

Playgrounds should be enclosed

If a playground is open, and there are no rules, chaos is possible.

So, don't keep your playgrounds open.

There are two ways to keep a playground more closed:

• Serve on http://localhost/ (the listener will not accept connections from other machines)
• Serve within a container

The former is ideal for local testing or UI loopback scenarios.

The latter is much safer to serve up. If you are running inside of a Docker container, that containerized operating system will serve as a cage that encloses your code. That is, even if they can break the rules of the playground somehow, they should not be able to escape the container.

If the container exposes nothing, even a compromised playground's damage will be limited (and can be quickly recovered from)

Playgrounds Rules

A playground should have a customizable set of rules.

These should match either AST conditions or Regular Expression patterns.

If any of these rules are violated, then the code cannot be played.

A number of rules should be applied by default.

A good default set might be:

• Only allow commands within the module
• No scoped variables
• Only whitelisted .net types (likely, primitives + [Math])
• No use of $executionContext or .ExecutionContext
• No inner functions
• No indeterminate loops