SharePoint 2010 Sandbox Solutions are Bad
Guest Author: Doug Ware
Elumenotion, LLC
I wish I could tell you that this was one of those posts where the title is a trick. It isn’t and there will be no ‘but in spite of all that it’s really great’ moral to this post. After spending a couple of weeks digging deeply into this architecture and its merits I am left profoundly disappointed by the reality of what is present in Beta 2. I hope that my position on this will change as we get closer to release and I also hope that if what follows is wrong the Internet will set me straight.
Most of my disappointment comes from the height of the walls around the sandbox and what I believe will be the result when this stuff hits the real world.
Issue #1 – No Access to SharePoint.WebControls Namespace
This one is really hard to understand – you can’t create a Web Part that uses any of the built in controls which you can use in SharePoint Designer! For example, I have a Web Part which I will talk about in a later post that hides the ribbon and the site actions menu if the user is not authenticated. The version I have won’t work as a sandbox solution because you can’t use the SPRibbon class in a sandboxed solution. So the sandbox solution has almost no control over the server side rendering of pages that contain sandboxed controls and much worse, prevent you from building pages that contain any of the built in SharePoint controls.
Issue #2 – No Elevation of Privileges = Less Security | More Complexity
In other words, sandboxed code can’t do anything that the current user can’t do. On the surface this seems reasonable. However, what if you want to collect data from a user and store the result somewhere that the user is unable to access? What if you want to display a subset of information to a user on a page but prevent access to the underlying data? Both are common requirements, but you can’t do it with a sandbox solution because your code is always under the user’s context. I predict that many people will take the easy way out and simply leave the lists that contain the data open to everyone. I also predict that many people will try to work around this restriction and create complex solutions that actually increase the attack surface.
Issue #3 – No Ability to Send Email
One of the methods that is explicitly blocked in the sandbox is SPUtility.SendEmail. As far as I know, there is no alternate method provided in SharePoint. However, you can use the ASP.NET email classes. The catch is that you can’t read information about the farm’s SMTP server so you have to create workarounds.
Conclusion
There’s more, but those are my main issues. My belief is that sandbox solutions as they stand today are a dead on arrival technology – at least where the server side object model is concerned for controlling the UI.
I think that they will be popular as a deployment model for applications that use the SharePoint.Client namespace with javascript and Silverlight. I can certainly hide the ribbon with javascript on the client – but I shouldn’t have to. I remain concerned that there is no good answer to #2 with regards to client side code. It would be nice if SharePoint allowed some sort of trusted caller infrastructure that allowed elevation to site owner. This should be possible at least with Silverlight.
However, you should not be fooled by the pronouncements that sandbox should be your default choice as was declared at PDC. If you are doing traditional development on a farm you own, the only thing you will get by going sandboxed is irritation from the sand.
Guest Author: Doug Ware
Elumenotion, LLC
Doug Ware is a SharePoint expert, the creator of AppDev’s popular series of SharePoint 2007 courses, and the author of Elumenotion SharePoint Skinner – the ultimate SharePoint branding tool. Doug is the founder of Elumenotion, a SharePoint training and consulting firm located in Atlanta, Georgia and has completed numerous SharePoint implementations cover a wide variety of businesses. Doug is also the leader of the Atlanta .NET User Group and is a frequent speaker at SharePoint Saturday, code camps and other events.
I totally agree with you. Sandbox solutions in the way they are don’t bring any advantages, because we have to develop specifically to it. a normal solution should run too as a sanbox solution.
Not sure SB Solutions are bad, but they definitely have much less promise than I initially thought they would. In addition to your points, you can not create a Visual Web part in Visual Studio 2010 as a SB Solution. To me that is the biggest issue because the people who are creating visual web parts are most likely the ones who would _need_ to deploy them as SB solutions.
Actually – the ASP.NET classes are not bad, as long as the server administrator has configured the local SMTP relay correctly – then your code should never need to know which SMTP server to use.
My response – http://blah.winsmarts.com/2010-1-Sandbox_solutions_are_pretty_damn_good.aspx
I assume they removed SendEmail capabilities to prevent spamming? Can they introduce a “point-heavy” email sending operation so that we can send on the order of 1 email a day to one addressee so I can send emails to the administrator? I ask because while I want to be able to spam hundreds of people a day, I can settle.
It would also help if Sandbox Solutions allow for a way to customize list alerts–allowing users to subscribe to list alerts (or add themselves to a SharePoint group which receives alerts) would solve the same problem (allow us to email a bunch of users) but would also solve the spam problem because it’s an opt-in solution.
Those are my thoughts.
Sahil – Haven’t seen you in a while. Hope things are well. Thanks for the dialog. Let’s see what comes back. — Mark
Ditto Mark! See you around sometime soon.
Great comments!
My reply to Sahil’s post: http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=108
With regards to SMTP. It is unusual for a SharePoint server to have the SMTP service active. The farm usually uses an external server on the same domain.
I added an update to the original post. I hope someone will come along and tell me I’m wrong about this, but it looks to me like you can forget almost everything you know about ASP.Net. If you want to sandbox.
The post is here: http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=105 but I have included the updated text below to save you from having to click! :)
Issue #4 – Almost No Server Side Rendering – Forget About Using ASP.NET
I thought I would try to work around my ribbon issue with a simple custom WebControl. Turns out that, since the sandbox assembly is installed in ProgramData\Microsoft\SharePoint\UCCache, the regular worker process (w3wp.exe) that renders pages can’t load the custom UI assembly because it has no knowledge of the UCCache location. The same applies to code behind assemblies for ASPX.
You can create WebParts (sorta/kinda) but they are also extremely crippled. See http://blah.winsmarts.com/2009-12-You_can_deploy_WebParts_as_Sandboxed_solutions__but.aspx