Artículo original publicado el miércoles, 21 de marzo de 2012

Hemos estado teniendo algunos buenos (en el sentido de "interesantes") debates últimamente acerca de la búsqueda y los proveedores de notificaciones personalizados.  Como se ha demostrado, hay instancias en las que tiene que instalar su proveedor de notificaciones personalizado en un cuadro de búsqueda (siendo "cuadro" algo que definiré abajo) con el fin de que el recorte de seguridad funcione correctamente en sus resultados de búsqueda.  Sin embargo, cuando esto se aplica, es diferente en función de si está usando FAST Search 2010 o SharePoint Search 2010.

En primer lugar, una pequeña explicación resultará probablemente útil aquí.  Cada vez que un usuario realiza una consulta, las notificaciones del token de usuario se descodifican.  Sin embargo, el servicio web de SiteData, que es lo que el rastreador usa para recuperar información de seguridad acerca del contenido, siempre devuelve notificaciones codificadas.  Por tanto, ¿cómo conciliar ese asunto?

En FAST Search 2010, las notificaciones se descodifican siempre antes de que las almacene el indizador de FAST Search 2010.  Hacemos esto porque los servidores de FAST Query no tienen los bits de SharePoint instalados, por lo que no pueden codificar las notificaciones.  Recuerde que las notificaciones de usuario vienen descodificadas, por lo que para hacer coincidir las notificaciones codificadas que el servicio web de SiteData devuelve, las notificaciones de usuario tendrían que codificarse para realizar una comparación.  Puesto que no podemos instalar un proveedor de notificaciones personalizado en un servidor de FAST Query, tenemos que descodificar las notificaciones que obtenemos del servicio web de SiteData, y para ello, cualquier proveedor de notificaciones personalizado que esté usando se debe instalar en el SSA de contenido FAST.  Hacerlo nos permite descodificar las notificaciones, almacenar las notificaciones descodificadas y, a continuación, cuando se presentan las notificaciones descodificadas para un usuario, podemos realizar una comparación.  Por tanto, en el caso de FAST, nos preocupa el uso de cualquier proveedor de notificaciones personalizado en el tiempo de rastreo.

Para SharePoint Search 2010 es casi el problema contrario.  SharePoint espera que se instalará en todas partes, por lo que funciona basándose en la premisa de que en el tiempo de consulta, puede codificar las notificaciones desde el usuario de manera que se pueda realizar una comparación a las ACL que se almacenan para el contenido.  Sin embargo, donde encontrará que esto fracasa es en el escenario en el que no ha implementado el proveedor de notificaciones personalizado en los servidores que están ejecutando el procesador de consultas, también conocido como el servicio de configuración de sitio y consulta.  En la mayoría de los casos, instala su proveedor de notificaciones personalizado en todos los servidores de su granja de servidores - WFE así como los servidores de aplicación.  El procesador de consultas necesita este proveedor de notificaciones personalizado instalado para codificar las notificaciones.  Por tanto, si todo se ejecuta en una granja de servidores única e instala el proveedor de notificaciones personalizado en todos los servidores, debería ser bueno.  La situación que surgió recientemente (y que motivó esta publicación) es un escenario donde tiene una granja de servidores servicios independiente y está consumiendo servicios de SharePoint Search desde dicha granja de servidores.  En ese caso, tiene que asegurarse de que se instala cualquier proveedor personalizado en todos los servidores de la granja de servidores de servicios que están ejecutando el servicio de consulta y configuración de sitio.  Si no lo hace, descubrirá que las notificaciones personalizadas de los usuarios no se pueden evaluar y, en consecuencia, normalmente no verán resultados de búsqueda devueltos.

Este fue un escenario interesante y motivó una gran solución de problemas por parte de un elenco de personajes... entre los que destaca especialmente mi hermano pequeño Luca por ayudarnos a superar el obstáculo final, así como Sanjeev y Michael P.  Gracias a todos por ayudarnos a comprender esto mejor.

Esta entrada de blog es una traducción. Puede consultar el artículo original en When Do You Need to Install a Custom Claims Provider for Search in SharePoint 2010