Tuesday, June 1, 2010

Sandbox solutions - Good or Bad?

Hey,

I have seen a lot of guys talking about sandboxing in SharePoint - if its a good thing or a bad thing to do.
I just thought I add my two cents as most of what I think about that subject was not covered by any of these posts... So I am beginning to think I'm a lone wolf.

Good

When are sandbox solutions actually are useful
The main benefit of sandboxing a solution as I see it is either when you wish to pilot a custom solution or a product for a trial period (and afraid it will have a bad impact on your farm), or when you wish to deploy a solution that was built for 1 department, and only they will use it within 1 site collection.
Sandbox allows your site owners to basically upload custom built code and run it off your server.
Scary, eh? I agree.
This is why Microsoft has limited the things and resources you can access within your sandbox solution. Otherwise, it would have been a security breach and no one would have use it - so please, stop complaining about the limitations that comes with it! So, to sum it up:
- Limited access, more secure
- Deployed using a browser, no need to access server
- Has no effect outside current site collection, safer to test / pilot anything risk free
- Easy to monitor

Bad

When sandboxing is not good for you
Overusing sandboxing is not that good, or may not be good for everyone. See, because of the optional security risk involved with sandboxing, Microsoft had to apply some restrictions on these solutions. As a part of the solution for this risk, a sandboxed environment is created for each instance of the solution that is deployed. This environment includes separate storage of the solution files, separate process that runs its code and separate memory to go with it. Imagine you have 400 sandboxed solutions, or just one that is deployed in 400 site collections - clearly this would be a huge waste of resources. Another good/bad thing (you decide) is that once you want to upgrade a sandbox solution that was deployed in 400 site collections - you need to do it manually one by one (or powershell it). Some consider this good as it allows you to test the new version before you deploy it everywhere. I consider it bad since even if you deploy it in full trust you can still pilot the new version as sandbox solution, right? :). I am ignoring of course of the limitations in sandbox solutions that might prevent you completely from using them, which are well covered in other blogs including how to overcome most of them using proxies, or storing resources in an assets library etc... So, to sum it up:
- Waste of resources
- Requires stronger servers or dedicated server to get same performance as full trust
- Hard to manage / upgrade

Ugly

When are sandbox solutions cross the line and start being just stupid
Some of the things in sandboxed solutions are just plain stupid, and do not make sense in security considerations for me at least. Like, say you deployed a sandboxed web part and added it to your page - you tested it and saw it is working OK. After a week of testing you retract the solution and deploy it as full trust. The dll is the same, the web part is the same, but it will no longer work on pages you added it before! you have to remove it and re-add it... Another thing that I cannot explain is why Page.ClientScript.Register**** methods do not work. As soon as I deploy as full trust the same code works like a charm. What is the security risk in using this API I wonder... I can just use the render method to write the same HTML to the page after all, no? Last, as I understand why sandbox solutions cannot access the hive folders, I do not understand why Microsoft did not implement some sort of virtual folders that allows you at least add resources and ASCX files for use withing your solution. So to sum it up:
- Have to remove, re-add and re-configure web parts when switching between deployment methods of same solution
- Cannot use Page.ClientScript to register scripts
- Cannot add resources in a simple way that will be the same regardless to which deployment method my customer chooses.

Please feel free to comment and give your input on this, I will try to update if and when I have more to say on the subject.

3 comments:

Ryan said...

Shai, Stopping Page.ClientScript.Register* isn't really to do with security but an artefact of how they have implemented sandbox solutions with the "Split Page Rendering System"

http://msdn.microsoft.com/en-us/library/gg615454.aspx

Still a bit of a cop-out as far as I am concerned - they could merge in clientscript registrations along with page content or the very least throw an exception to stop you scratching your head for an hour when it fails silently...

Shai Petel said...

Hi Ryan,

My point exactly! blocking this and many other APIs serve no purpose from the sandbox goals:
1. it does not help security
2. does not allow you to "braech" the site collection sandbox scope
3. does not help server performance or stability

In any way I look at it - this and many more APIs that are not working are to say the least - a design bug.

I expected at least to have another channel through special sandbox API that will expose those options, or like you said to get a real exception - but now... left with just banging the head against the screen...

BTW, the real reason is, just, that the entire "Page" object is inaccessible.

Anonymous said...

Ryan,
Thank you very much for comment about Split Page Rendering System.

I didn't understand before i read about Split Rendering, why i see in fiddler two resposnses. First correct and other empty.
On screen i see empty one.

So this table is very importnat:

Unmergable Type
Implications and Remarks

ClientScriptManager
Sandboxed code should not write to the ClientScript property. However, client-side script can be registered with the page in other ways. For example, you could embed the script as a LiteralControl and add it to a control collection in a CreateChildControls() method.

ScriptManager
Sandboxed code should not add a ScriptManager object to the controls collection of any object.

Cache
Sandboxed code should not write to the Cache property.

MasterPage
Sandboxed code should not write to the Master property. However, it can point the page to a different master page by writing to the MasterPageFile property.

HttpSessionState
Sandboxed code should not write to the Session property.