Def: A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment.
In SharePoint 2007, custom code requires the farm administrator to trust the code running on the server. In SharePoint 2010 we are introducing a new SharePoint custom code sandbox with isolation and resource limitations (memory, SQL, CPU) that allows administrators to let others safely add and consume custom solutions without impacting overall farm performance and stability.
The main benefits of using sandboxed solutions are as follows:
Sandbox Proxy:
The thing is, sandbox solutions are great, because they restrict the average joe developer, and they allow the farm administrator to manage and monitor and even validate. But, sometimes you need to negotiate the boundaries of what a sandbox solution can do! For instance, lets say, we are presented with a crazy requirement that through a sandbox solution, you need to create a file on the disk of the web server! To make things even more interesting, the sandbox solution packages a webpart, which presents the user with a simple textbox. The file contents will be whatever the user typed into that text box, through a web based solution, in a sandboxed solution!
The solution to this problem is to write a full trust proxy!
The obvious question you may have here is, if you can get around the whole notion of sandbox solutions using full trust proxies, then why even bother with sandbox solutions? What is that boundary good for, if it can be broken!?
Well, take heart! The idea here is to break your architecture down into two major pieces,
Before going into details of Sandbox proxies, first we need to have a clear understanding of Sandbox architecture, which we will cover in next post.
In SharePoint 2007, custom code requires the farm administrator to trust the code running on the server. In SharePoint 2010 we are introducing a new SharePoint custom code sandbox with isolation and resource limitations (memory, SQL, CPU) that allows administrators to let others safely add and consume custom solutions without impacting overall farm performance and stability.
The main benefits of using sandboxed solutions are as follows:
- Sandboxed solutions can be added to a production SharePoint Server environment without the risk of affecting processes outside the sandbox.
- Site collection administrators can deploy sandboxed solutions. This frees farm administrators from this task.
- Scalability and flexibility are increased because sandboxes run in a separate process that can be restricted by quotas, and their effect on the farm can be monitored.
- A solution does not have to be modified or recompiled if it is moved from a sandbox to running directly on the farm.
SandBox Solutions support the following SharePoint item types:
- List definitions
- List instances
- Onet.xml
- WebTemplate Feature element instead of Webtemp.xml
- Content Types/Fields
- Navigation
- Module/files
- Feature callouts
- Web Parts derived from WebPart
- Event receivers
- SPItemEventReceiver
- SPListEventReceiver
- SPWebEventReceiver
- Custom Actions
- Workflows
- Custom Action groups
- HideCustomAction element
- Content Type Binding
- Web Application-scoped Features
- Farm-scoped Features
- CustomPropertyToolPart Class
- Programmatic workflow
- Event receivers
- SPLimitedWebPartManager
- Timer jobs
- Visual WebParts
- SharePoint mapped folders (e.g. “_layouts”, and “images”)
- ADO.NET
- System.IO
- System.Security.Cryptography
- System.Web.UI.ClientScriptManager
Aspect | Farm | Sandbox |
|---|---|---|
Deployment process | Add the solution, and then deploy it to the farm. | Upload the solution to a site collection, and then activate it in the site collection. |
Who can deploy | Farm administrator. | If the solution contains an assembly, only a site collection administrator can deploy it. If the solution does not contain an assembly, a user who has the Full Control permission level at the root of the site collection can deploy it. |
Data access | Unrestricted. | The solution can only access content from the site collection in which it was deployed. |
Process the solution runs in | Unrestricted IIS worker process, or whichever process the solution is deployed into. | Separate worker process that has restricted permissions. |
Code access security | The solution developer can set the code access security policy when packaging the solution. | Restricted. |
Monitoring | Not monitored. | Monitored, and limited by quotas set by the farm administrator. |
Load balancing | Varies, based on the kind of solution. | Configurable separately from non-sandboxed solutions. |
Solution functionality | Unrestricted. | Restricted, as described in What sandboxed solutions cannot do, earlier in this article. |
Sandbox Proxy:
The thing is, sandbox solutions are great, because they restrict the average joe developer, and they allow the farm administrator to manage and monitor and even validate. But, sometimes you need to negotiate the boundaries of what a sandbox solution can do! For instance, lets say, we are presented with a crazy requirement that through a sandbox solution, you need to create a file on the disk of the web server! To make things even more interesting, the sandbox solution packages a webpart, which presents the user with a simple textbox. The file contents will be whatever the user typed into that text box, through a web based solution, in a sandboxed solution!
The solution to this problem is to write a full trust proxy!
The obvious question you may have here is, if you can get around the whole notion of sandbox solutions using full trust proxies, then why even bother with sandbox solutions? What is that boundary good for, if it can be broken!?
Well, take heart! The idea here is to break your architecture down into two major pieces,
- The first piece that you will deliver completely using sandbox solutions!
- The second piece is the API you will build using full trust proxies, that the sandbox solutions can leverage.
Before going into details of Sandbox proxies, first we need to have a clear understanding of Sandbox architecture, which we will cover in next post.
No comments:
Post a Comment