Guest Author: Doug Ware
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.
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.
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
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.