miércoles, 24 de septiembre de 2008

Acceso anónimo en Sharepoint 2007

Cuando apareció la versión 2007 de Sharepoint, una de las novedades que más agradecimos las personas que habíamos trabajado con versiones anteriores era el uso de la arquitectura de autenticación de .NET 2.0. Esto permitía utilizar los proveedores estándar para autenticarse contra directorio activo o SQL Server mediante FBA, o incluso crear nuestros propios proveedores de autenticación. En relación a esto, sorprendía también lo relativamente fácil que era habilitar el acceso anónimo a los portales. Los pasos a seguir son los siguientes:
  • Acceder a la Administración Central de Sharepoint
  • En la pestaña Administración de Aplicaciones, acceder a Proveedores de autenticación dentro del grupo Seguridad de aplicación
  • Seleccionar la aplicación web donde queramos habilitar el acceso anónimo
  • En la zona Default o en cualquier zona que tengamos definida y en la cual queramos habilitar acceso anónimo, marcar la opción Acceso Anónimo y guardar los cambios

A continuación, en nuestro portal, y desde la página inicial, efectuamos las siguientes operaciones:

  • En el menú Acciones de sitio, seleccionar Personas y grupos
  • En el menú lateral izquierdo, seleccionar Permisos del sitio
  • Desplegar el menú Configuración de la lista que aparece, y acceder a la opción Acceso anónimo
  • Marcar la opción Todo el sitio y aceptar los cambios

Con esto ya deberíamos tener acceso anónimo al sitio. Es posible, sin embargo, que nos interese acceder de manera anónima a las listas (páginas /Forms/Allitems.aspx, /Forms/DispForm.aspx, por ejemplo). Si éste es el caso, deberemos hacer una cosa más. Resulta que por defecto, los sitios de Sharepoint se crean con una característica activada que bloquea este acceso. Para desbloquearlo, debemos utilizar el comando stsadm de la siguiente manera:

stsadm -o deactivatefeature -url http://url_del_sitio -filename ViewFormPagesLockDown\feature.xml

martes, 23 de septiembre de 2008

Calidad y seguridad al desarrollar sobre Sharepoint

Cada día nos encontramos con más organizaciones que utilizan Sharepoint y, como todos sabemos, es bastante común extender la plataforma para satisfacer las necesidades específicas de cada una de ellas.

Aquellos que hemos trabajado con anteriores versiones del producto sabemos que la popularidad de la plataforma no era muy alta, debido en parte a sus propias carencias, y en parte a lo complejo que resultaba extenderla que, a la postre, derivaba en desarrollos no del todo ortodoxos más conocidos como ñapas.

Bien, Sharepoint 2007, como todos sabéis, está construido sobre la plataforma .NET. Esto hace que extender las funcionalidades del producto sea mucho más sencillo pero esto acaba convirtiéndose en un arma de doble filo. El hecho que el desarrollo sea sencillo permite producir de una manera rápida extensiones del producto sin tener un dominio elevado de la plataforma, y esto puede llevar a graves problemas de calidad, seguridad o de rendimiento que normalmente no son imputables a la propia plataforma.

Aquí dejo un enlace a un interesante documento que trata de poner un poco de luz en este asunto. Entre otras cosas, podréis ver una checklist que todos tendríamos que tener en cuenta a la hora de construir cualquier elemento por encima de Sharepoint.

http://technet.microsoft.com/en-us/library/cc707802.aspx

lunes, 22 de septiembre de 2008

Sharepoint y virtualización

Últimamente mucha gente me pregunta cómo desarrollar sobre Sharepoint con una máquina de escritorio con Windows Vista (o XP), y mi respuesta siempre es: usad máquinas virtuales. Bien, voy a escribir un post explicando en detalle qué son, para qué sirven y cómo trabajar con máquinas virtuales, para que pueda servir de guía a todas aquellas personas que se inician en este mundillo. Para empezar, tenemos que conocer las diferentes herramientas de virtualización que podemos encontrar en el mercado. Yo diferenciaría entre dos grandes compañías: VMWare y Microsoft. Históricamente, VMWare ha ido un paso por delante de Microsoft en esta área -lógico teniendo en cuenta que la virtualización era su core business- La tónica ha cambiado de un tiempo a esta parte y, aún sin ser un experto en infraestructura, opino las últimas versiones de los productos de Microsoft están algo por delante de las de sus competidores. Evidentemente esto es una opinión personal y cada uno tendrá la suya, pero como información al respecto encontraréis toda la que queráis, en este post hablaré sólo de los productos de Microsoft, que son con lo que yo me siento más cómodo. Deberíamos conocer principalmente 3 productos: Virtual PC, Virtual Server y Hyper-V. Virtual PC, actualmente en la versión 2007 es, por su simplicidad de uso la principal herramienta a ser tenida en cuenta. Tiene alguna limitación respecto a los otros dos productos, pero permitirá simular cualquier entorno servidor (en 32 bits) sin ningún problema. Virtual Server, actualmente en la versión 2005 R2, es la versión para servidores de Virtual PC. Tiene algunas ventajas, mayoritariamente en temas de rendimiento pero, aunque se puede instalar sobre Windows XP o Windows Vista, la dificultad de uso en comparación con VPC no la hacen aconsejable para entornos de desarrollo. Hyper-V es un caso aparte. Prácticamente recién salido del horno, sólo funcionará con equipos Windows Server 2008. Para los que piensen que no es un sistema para equipos de usuario, haced una búsqueda de Windows Server 2008 Workstation y os llevaréis alguna sorpresa. Pese a que no es tan fácil de usar como VPC, alguna de sus características como es la posibilidad de crear máquinas virtuales de 64 bits la hacen la opción más interesante de las comentadas. Una vez seleccionado el producto a utilizar, es conveniente decidir una buena estrategia de máquinas virtuales para el trabajo diario. Básicamente, para desarrollar sobre Sharepoint necesitamos lo siguiente:
  • Windows Server
  • SQL Server
  • Sharepoint
  • Visual Studio
  • Office (Al menos designer)
  • etc.

Una máquina virtual con todo esto podría irnos bien pero, ¿qué pasará si necesitamos trabajar con Visual Studio 2005 en un proyecto y con 2008 en otro? ¿qué pasará cuando queramos probar SQL Server 2008? Para evitarnos el hecho de ir reinstalando máquinas en función de los requerimientos tenemos el concepto de discos diferenciales. Podemos hacer un disco diferencial en cualquier punto de la vida de una máquina virtual, de manera que siempre podremos crear una nueva máquina partiendo de una de las bases de las que dispongamos. Además, esto nos puede servir también para trabajar en diferentes proyectos, sin necesidad de reinstalar todo el software cada vez.

Está claro que esto puede parecer mucho trabajo inicialmente, y lo es. Pero creedme, el tiempo se recupera con creces cuando preparas entornos de desarrollo, o cuando necesitas recuperar el estado de un proyecto que no tocas desde hace meses.

Violation of PRIMARY KEY constraint 'PK__#ExportObjects____XXXXXXXX

Hoy toca de hablar de un tema algo más concreto. El título de este post hace referencia a un error con el que me he encontrado en un proyecto con el que estoy trabajando actualmente. Para ponernos un poco en contexto, deciros que es un portal de publicación multiidioma de MOSS. Para los que hayáis trabajado en proyectos similares, supongo que todos conocéis las Variaciones de sitio que funcionan de una manera más que correcta para casos simples de publicación. Bien, el proyecto comenzó como cualquier otro, creando una estructura básica, estableciendo las variaciones y creando las jerarquías. Hasta aquí todo correcto. Unas cuantas pruebas de flujos de traducción y todo parecía funcionar correctamente. Hasta que, en un momento dado, las variaciones empiezan a fallar sin motivo aparente, sin mensaje de error informativo. Unas cuantas revisiones de los ficheros de LOG y del visor de sucesos y, cuál fue mi sorpresa al encontrarme con infinitos errores "Violation of PRIMARY KEY constraint 'PK__#ExportObjects____XXXXXXXX". Sin saber realmente de donde procedía el error, me puse a mirar en internet y encontré muchas referencias relacionadas con el control de versiones en las librerías SiteCollectionImages y Style Library. Os dejo alguna de las referencias que he encontrado, por si os pudieran interesar: http://www.sharepointblogs.com/koning53/archive/2007/11/23/violation-of-primary-key-constraint-pk-exportobjects-xxxxxxxx.aspx http://www.sharepointblogs.com/niklas/archive/2008/01/28/wss-incremental-deployment-job-and-violation-of-primary-key-constraint-error.aspx También encontré una algo más profunda que hablaba sobre la base de datos de Sharepoint. Intenté investigar un poco, pero no me parecía recomendable tocarla, ni mucho menos probarlo en un servidor en producción: http://www.sharepointblogs.com/pholpar/archive/2007/05/22/primary-key-violation-when-using-the-spexport-object.aspx La mayoría de referencias que veía eran anteriores al SP1, y muchas dirigían a un hotfix que, por supuesto, intenté instalar. Error, no se podía instalar en servidores con el SP1 instalado. Al final, a un paso de dejarlo por imposible y tirarme de cabeza contra la base de datos, en uno de los comentarios de uno de los posts que he dejado un poco más arriba, vi lo siguiente: There is a post SP1 hotfix available from MS. The name is wss-kb950279-fullfile-x86-glb.exe. Bien, descargo el hotfix de aquí: http://thehotfixshare.net/board/index.php?autocom=downloads&showfile=7293 ejecuto el wizard de MOSS y, ¡Bingo! todo vuelve a la normalidad. Ahora sólo me pregunto si sería aconsejable ejecutar el hotfix en todos los servidores de producción que alojan portales multiidioma, o espero a que el problema se reproduzca. Creo que haremos caso de la máxima: "Si funciona, no lo toques..."