Pregunta

Tengo un servicio web personalizado que se ejecuta en SharePoint 2007 y SharePoint 2010. Actualmente estoy probando solo en SharePoint 2010 en mi entorno de desarrollo. Tengo algún código que hace lo siguiente:

bool allowUnsafeUpdates = web.AllowUnsafeUpdates;
try
{
    web.Properties[webPropertyBagKey] = value;
    web.AllowUnsafeUpdates = true;
    try
    {
        web.Properties.Update();
    }
    catch (Exception ex)
    {
        // Update failed likely due to security reasons, try with elevated privileges
        SPSecurity.RunWithElevatedPrivileges(delegate()
        {
            using (SPSite elevatedSite = new SPSite(web.Site.ID))
            {
                using (SPWeb elevatedWeb = elevatedSite.OpenWeb(web.ID))
                {
                    bool elevatedAllowUnsafeUpdates = elevatedWeb.AllowUnsafeUpdates;
                    try
                    {
                        elevatedWeb.Properties[webPropertyBagKey] = value;
                        elevatedWeb.AllowUnsafeUpdates = true;
                        elevatedWeb.Properties.Update();
                    }
                    finally
                    {
                        elevatedWeb.AllowUnsafeUpdates = elevatedAllowUnsafeUpdates;
                    }
                }
            }
        });
    }
}
catch (Exception ex)
{
    // log exception, but don't bubble it up...
}
finally
{
    web.AllowUnsafeUpdates = allowUnsafeUpdates;
}

Antes de llegar al código anterior, el objeto SPWEB (Web) se ha abierto utilizando una técnica para hacerse pasar por el propietario del sitio determinando el token de usuario del propietario del sitio e instanciando el objeto SPSITE al proporcionar el token de usuario y obtener el SPWEB desde allí. Entonces, las llamadas de la API de SharePoint ya tienen privilegios bastante elevados.

Lo que encontré es que mi primer web.properties.update () parece funcionar bien si me autentico en el servicio web utilizando el propietario de un sitio. Sin embargo, si me autentico en el servicio web utilizando un usuario que simplemente tiene acceso de lectura a la web, mi llamada web.properties.update () falla. No estaba mal, esperaba, porque puedo ejecutar con privilegios elevados (lo que hace un reverttoself y se ejecuta como propietario del grupo de aplicaciones). Ese código funciona correctamente, pero poco después de que se ejecuta el código, el hilo aborta mientras procesa algunas otras instrucciones (como el "{" después de otro bloque de intento en algún otro código.

La buena noticia es que si acabo de ejecutar los primeros primeros logros en todo momento, entonces parezco estar bien. Básicamente, atrapar el intento original deja un problema persistente a pesar de que no burbujean nada.

¿Alguna idea de lo que está pasando aquí? Me preocupa que haya otros lugares en los que pueda encontrarme con esto además de ahorrar spweb.properties.

¿Fue útil?

Solución

Es posible que desee intentar apagar el manejo incorporado de SharePoint de excepciones de AccessDenied que, por defecto, parecen cancelar la solicitud actual y a menudo causa threadabortexcepciones.

Spsecurity.CatchAccessDeniedException

Configurar esta propiedad en falso debería permitirle manejar la excepción de AccessDenied usted mismo. Recuerde restaurar su valor una vez que haya terminado.

Otros consejos

He encontrado una situación similar, al menos creo que esto podría ser. La forma de resolverlo era entender lo que realmente estoy haciendo al llamar, por ejemplo,using (SPSite elevatedSite = new SPSite(web.Site.ID))Desde dentro de un delegado en runwithelevatedprivileges.

La cuestión es que parece que el delegado se está ejecutando en un hilo diferente. Entonces, en lugar de usar web.site.id (que está en otro hilo), debe almacenar todos los datos que necesitará (todas las ID, etc.) en variables simples antes de ingresar al delegado. Eso debería cuidar el hilo que aborta.

Licenciado bajo: CC-BY-SA con atribución
scroll top