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.
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.- Limited access, more secure
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:
- 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
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
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.