SharePoint 2010: Limitaciones en las soluciones Sandbox (II)!

Como continuación al primer post sobre limitaciones en las soluciones SandBox en cuanto a que tipo de artefactos se pueden crear y el ámbito a nivel de desarrollo en el que nos podemos mover (Colección de Sitios hacia abajo), en esta ocasión quería entrar en un poco más de detalle en estas limitaciones teniendo en cuenta el modelo de ejecución de las soluciones SandBox. Básicamente, todo el código que corre dentro del servicio de SandBox está sujeto a una serie de restricciones tanto de ejecución como de acceso. Hay dos sistemas de restricciones:

• Uno que se aplica únicamente a toda llamada que se realice a cualquier ensamblado exceptuando Microsoft.SharePoint.dll.
• Otra que se aplica únicamente a toda llamada que se realice al modelo de objetos SharePoint incluido en Microsoft.SharePoint.dll y otros ensamblados como Microsoft.SharePoint.Linq.dll.

¿Cómo se aplican estas restricciones? Para el primer tipo de llamadas a ensamblados, se definen dos mecanismos:

• Una política muy restrictiva de seguridad de acceso a código (CAS) que se encarga de limitar lo que el código ejecutándose en el proceso de SandBox puede hacer (Nota: Esta política si permite acceder a ensamblados de Microsoft Office con un “strong-named”). Esta política se encuentra definida en el archivo web.config bajo la ruta %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG,  impone restricciones como:

• La imposibilidad de llamar a código no manejado desde el código de una solución SandBox.
• La imposibilidad de llamar a las APIS de reflexión de .NET Framework 3.5 desde el código de una solución SandBox.
• La condición de que para poder llamar desde código de una solución SandBox a ensamblados de .NET Framework 3.5 se necesita que tengan el atributo AllowPartiallyTrustedCallersAttribute.

   1: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

   2: <configuration>

   3:   <system.web>

   4:       <httpModules>

   5:          <clear/>

   6:       </httpModules>

   7:     <httpHandlers>

   8:       <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="true"/>

   9:     </httpHandlers>

  10:     <securityPolicy>

  11:       <trustLevel name="WSS_Sandbox" policyFile="..\config\wss_usercode.config" />

  12:     </securityPolicy>

  13:     <trust level="WSS_Sandbox" originUrl="" />

  14:   </system.web>

  15:   <runtime>

  16:     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

  17:       <probing privatePath="assemblies" />

  18:       <dependentAssembly>

  19:         <assemblyIdentity name="Microsoft.SharePoint" publicKeyToken="71e9bce111e9429c" culture="neutral" />

  20:         <bindingRedirect oldVersion="0.0.0.0-14.900.0.0" newVersion="14.900.0.0" />

  21:       </dependentAssembly>

  22:     </assemblyBinding>

  23:   </runtime>

  24: </configuration>

• A través de un token de seguridad con privilegios mínimos que impide que el worker process del servicio de SandBox:
  • Tenga permisos para leer o escribir en el sistema de archivos.
  • Tenga permisos para realizar llamadas a la red, de forma que solo se pueden acceder a recursos disponibles en el servidor dónde se está ejecutando el proceso.
  • Tenga permisos para escribir en el registro.
  • Tenga permisos para llamar a cualquier ensamblado que no esté en la GAC, incluso aunque disponga del atributo AllowPartiallyTrustedCallersAttribute.

Para el segundo sistema de restricciones, se define una versión “shim” del MO de servidor de SharePoint que junto con el MO completo son cargados por uno de los dos procesos que constituyen el servicio de SandBox (en concreto por SPUCWorkerProcessProxy.exe) que impiden que se llamen a objetos de la API no permitidos desde una solución SandBox. Además, existen otros dos ensamblados que son usados por este sistema y que se cargan en el Worker Process del servicio de SandBox (Microsoft.SharePoint.UserCode.dll) y en el proxy comentado (Microsoft.SharePoint.SubsetProxy.dll). El mecanismo de uso de estos ensamblados “shim” por los procesos del servicio de SandBox es el siguiente:

• Cuando una solución SandBox hace uso de un parte permitida de la API de SharePoint, el primero de los ensamblados pasa la llamada al segundo en el proceso de proxy, que a su vez la pasa a la API estándar en Microsoft.SharePoint.dll.
• Los resultados de la llamada realizad se pasan al código original que la realizó.

Como ejemplo de restricción en cuanto al uso del MO de SharePoint tenemos:

• No se puede acceder a la clase SPWebApplication ni a cualquiera definida bajo Microsoft.SharePoint.Administration.
• No es posible realizar una elevación de privilegios en el código que se ejecute en modo SandBox.
• No se pueden usar los controles definidos en Microsoft.SharePoint.WebControls de manera que estamos restringidos al uso de controles ASP.NET.
• …

El listado completo de APIs dentro de Microsoft.SharePoint.dll que se pueden usar lo podéis encontrar aquí Microsoft.SharePoint.dll APIs Available from Sandboxed Solutions. Finalmente, otra limitación ya comentada en este blog es que a nivel de despliegue de una solución SadnBox está prohibido incluir cualquier tipo de archivo que se tenga que copiar en el servidor físico como controles de usuario, páginas de aplicación, o imágenes. Para más información recomendable ver SharePoint Deployment Models.