ISP Sandbox

What does a WebDNA Sandbox do?

Basically it provides a way for a WebDNA admin to designate a particular folder, and its subfolders, as a WebDNA Sandbox. This means that WebDNA templates running from within that folder will not be able to view, manipulate, delete, or create any files outside of their root Sandbox folder.

This enables a WebDNA ISP to allow multiple WebDNA developers access to the same machine knowing that each sites is 'locked down' to its own root folder.

But that's not all...

Each sandbox site has its own 'WebCatalog Prefs' file called Sandbox Prefs, which includes nearly every preference you would find in the master WebCatalog Prefs file.

Each Sandbox has its own Triggers process

Each Sandbox has its own Emailer process

Each Sandbox has its own Users database

Each Sandbox has its own Admin section, which includes nearly all the templates you would find in the main WebDNA admin pages.

Each Sandbox has its own Globals, EmailFolder, EmailCompleted folder, etc....

If fact, each Sandbox has nearly every database, template, and system folder you would normally find in the main WebDNA engine folder.

Some Experimentation

Lets try a database search on an arbitrary db file that we know is outside the Sandbox...

[search db=../../../../test.db&eqIDdata=1]
[numfound]
[/search]

Results....

WebDNA Sandbox security does not allow access to: *\test.db*An unknown error occurred:
DBError
../../../../test.db

WebDNA Changes

Here is a list of WebDNA Tags and Contexts whose behavior is altered when used inside a WebDNA Sandbox...

These contexts can only operate on files and or folders that exist within the Sandbox root folder, or the sandbox 'globals' folder when the '^' prefix is used.

[appendfile]
[writefile]
[renamefile]
[deletefile]
[movefile]
[copyfile]
[fileinfo]
[listfiles]
[waitforfile]
[copyfolder]
[createfolder]
[deletefolder]

These operations can only operate on a cart or files that exists within the sandbox root, or the sandbox 'globals' folder when the '^' prefix is used.

[orderfile]
[purchase]
[removelineitem]
[clearlineitem]
[setlineitems]
[setheader]

Will only flush the databases that exists within the sandbox root or globals folder.

[flushdatabases]

These contexts will only operate on database files that exist within the sandbox root or globals folder.

[commitdatabase]
[listdatabases]
[closedatabase]
[listfields]
[search]
[lookup]
[replace]
[append]
[delete]

Uses the 'local' sandbox 'users.db' file.

[protect]

Both these tags use the 'format' preferences in the local sandbox prefs file.

[date]
[time]

Can only include a file that exists within the sandbox root or globals folder.

[include]

Uses the local sandbox email settings. Resulting email files are written to the sandbox 'EmailFolder'.

[sendmail]

These contexts require special handling, discussed later.

[object]
[dos]
[applescript]

Uses the local sandbox 'StandardConversions.db' file. If a database is specified, it must exist within the sandbox root or globals folder.

[convertchars]

Can only be used with a database that exists within the sandbox root or globals folder.

[convertwords]

Misc. Sandbox Notes

The '/' path prefix will be relative to the Sandbox root folder.

The '^' global prefix will refer to the Sandbox globals folder and not the main WebDNA globals folder.

The 'absolute path' specifier '*' can still be used with a sandbox, as long as it refers to a path that exists within the sandbox root or globals folder.

WebDNA error messages will be retrieved from the sandbox ErrorMessages.db, and not the main WebDNA ErrorMessages.db

WebDNA error logs and debug files will be created within the sandbox system folder, and not the main WebCatalogEngine folder.

Shell, DOS, Applescript

The [shell], [dos], and [applescript] contexts require special handling when used within a WebDNA Sandbox.

Shell, DOS, and Applescript code can no longer be explicitly defined within these contexts, when used in a WebDNA Sandbox. Instead, the desired code must be submitted to the WebDNA admin for approval. If approved, the 'code snippet' is added to the WebDNA Sandbox 'Scripts' database, with a unique ID code. This ID code is then used by the Sandbox programmer.

For example...

A WebDNA sandbox programmer wants to execute the DOS command. "dir c:\". The programmer submits the code snippet, "dir c:\", to the WebDNA admin. The admin approves the code, and inserts the code into the WebDNA Sandbox Scripts database with a unique ID of '111'. The WebDNA admin then returns the ID to the Sandbox programmer. The Sandbox programmer then uses the ID as follows...

[DOS scriptID=111][/DOS]

The same applies when using the [shell] context.

The [object] context is handled in a slightly different way. For this case, the submitted 'code snippet' is the 'parameter list' that would normally be passed into the context.

For example...

[OBJECT objname=SystemInfo.SysInfo.1&type=0[!]
[/!]&call=GetFreeDiskSpace[!]
[/!]&param1=C:\&param1type=str][/OBJECT]

would become...

[OBJECT SCRIPTID=123][/OBJECT]

The WebDNA admin having recorded the text:

"objname=SystemInfo.SysInfo.1&type=0[!]
[/!]&call=GetFreeDiskSpace[!]
[/!]&param1=C:\&param1type=str"

into the Sandbox scripts database with an ID of 123.