Detectar inicio de sesión de usuario en SharePoint

Dado que el uso del evento Session_Start en las aplicaciones web de SharePoint es un mecanismo de más que dudoso éxito:

http://stackoverflow.com/questions/2948471/handling-session-start-and-session-end-events-global-asax-sharepoint

http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/79f69293-a91c-4426-acac-ff23030db1ee/

propongo un método para detectar cuando un usuario ha empezado sesión en una aplicación web SharePoint. Aprovechando que disponemos de master pages, podemos incrustar en ellas un control de servidor que se ejecutará en todas las páginas y añadirle la siguiente lógica:

protected override void OnLoad(EventArgs e)
{
    base.OnLoad(e);
    if (HttpContext.Current.Request.Cookies["Mi_Cookie_Sesion"] == null)
    {
        // Realizar nuestras acciones de inicio de sesión
        // ...

        HttpContext.Current.Response.Cookies.Add(new HttpCookie("Mi_Cookie_Sesion"));
    }
}

Resumiendo, crear una cookie de sesión ASP.NET (objeto HttpCookie sin tiempo de expiración) y comprobar su existencia al iniciar. Las cookies de sesión persisten mientras el usuario está autenticado y caducan cuando hace logout o cuando cierra el navegador.

Activar el visor de XPS en Windows Server 2008

Es muy fácil, pero puede volverse uno loco intentando abrir ficheros XPS en Word y que éste diga:

The file ***.xps cannot be opened because there are problems with the contents.

o intentar abrirlos en Internet Explorer y que éste, en lugar de abrirlos, muestre el diálogo de descarga de fichero.

Simplemente hay que activar la feature de servidor XPS Viewer.

A partir de entonces, el programa estará disponible en %systemroot%\system32\xpsrchvw.exe y podremos seleccionarlo como programa predeterminado para la extensión .XPS

Herramientas para consultar el Directorio Activo

Vamos a arrejuntar algunos recursos e ideas interesantes a tener en cuenta cuando queremos examinar un Directorio Activo que no gestionamos. Si no tenemos acceso al controlador de dominio (ni ganas) pero necesitamos navegar por las OU’s, los usuarios, los equipos o el esquema, disponemos de lo siguiente:

• Las herramientas de Active Directory Services incluídas en Windows 2008. Se instalan como Features en la consola de servidor e incluyen

• el Snap-in de MMC que todos conocemos de Active Directory Users and Computers (evidentemente restringido a los permisos del usuario con que estemos navegando). Probablemente la forma más directa de consultar usuarios, equipos y sus propiedades básicas.

• el Active Directory Administrative Center, una herramienta GUI algo más avanzada que el Snap-in y, chico, un descubrimiento. Puedo ver el listado completo de atributos (incluídos los extendidos), filtrar, hacer búsquedas y guardar consultas.
• 
• 
• la consola Active Directory module for PowerShell, con CmdLets que implementan funciones comunes de gestión del AD. La referencia completa de CmdLets está en http://technet.microsoft.com/en-us/library/ee617195.aspx
• Si no disponemos de permisos de instalación para añadir Features en el servidor, quizá nos interese una herramienta de terceros como Active Directory Explorer de Sysinternals, muy completa y con opciones avanzadas de edición, como por ejemplo, los snapshots del AD y la comparación entre ellos.



• Por otra parte, disponemos de otra herramienta en forma de librería de CmdLets de Powershell: el ActiveRoles Management Shell de Quest Software (los de PowerGUI), que proporcia bastantes más opciones de las que ofrece el Active Directory Module de MS. Este blog es una buena referencia de posibles operaciones a realizar sobre el AD: http://dmitrysotnikov.wordpress.com/category/ad-cmdlets/  Por ejemplo, listar todos los atributos existentes se resolvería con el siguiente (y simple) comando:
• Get-QADUser -ReturnPropertyNamesOnly -IncludeAllProperties
• Finalmente, cabe comentar que, si todo esto nos queda pequeño, para implementar nuestras consultas personalizadas y aplicar la lógica añadida que deseemos tenemos el namespace System.DirectoryServices de .NET para atacar las interfaces de servicio de AD.

“Attempted to use an object that has ceased to exist” al eliminar web parts

Otra batallita más para cuando sea abuelo. En una página hay dos instancias de mi web part personalizado (es decir, con código mío). Todo va bien hasta que, una vez configuradas las propiedades del primero, me pongo a configurar las del segundo. Guardo la página y –puf- las propiedades no se han guardado. Qué raro. Intento el eliminar el web part y aparece esta alarmante excepción:

Attempted to use an object that has ceased to exist. (Exception from HRESULT: 0x80030102 (STG_E_REVERTED))

Afortunadamente, googleando (yo también lo uso, Chan), llegamos a la conclusión que mi código está usando tácticas de guerrilla para cargarse el contexto de SharePoint:

SPSite site;

try
{

// site = new SPSite 
site = SPContext.Current.Site; // miedo y pavor

// ... decenas de líneas de código más tarde

}
finally
{
    if (site != null) site.Dispose();  // ouch!
}

Evidentemente si liberas un SPSite obtenido del contexto, el siguiente web part que intente usarlo va a acabar con la cara negra de pólvora. Así pues, prescindo del Dispose y mi página ya funciona con total normalidad. Circulen, no hay nada que ver.

URLs directas de edición de página y web parts

Grabado a fuego quede este post para poder consultarlo siempre que olvidemos cuales son las URL para ir directamente a la edición de páginas de publicación:

http://sitio/Pages/pagina.aspx?ControlMode=Edit&DisplayMode=Design

así como a la página de mantenimiento de página de elemento web (Webpart Maintenance Page):

http://sitio/Pages/pagina.aspx?Contents=1

o bien

http://sitio/_layouts/spcontnt.aspx?&url=%2fsitio%2fPages%2fpagina.aspx