SharePoint App Catalog And Missing Apps

Another weird SharePoint app bug happened yesterday. The solution was fairly easy once you know what’s going on, but it’s just weird altogether.

SYMPTOMS

You have a custom app in your SharePoint 2013 App Catalog.

A custom app inside app catalog under Apps for SharePoint
A Custom App Inside App Catalog

You want to add this app to a SharePoint site.  You can’t find your app in the “From Your Organization” section when you click at “Add an app” in a site.

The App Is Missing From "Your Apps"
The App Is Missing From “Your Apps”

CAUSE

I first suspected that the current user doesn’t have permissions to add an app. However, the user is the site collection administration and thus has the permission to install an app.

Yet…a slight detail. The App Catalog site is, well, a SharePoint site. With its own permissions. And, by default, containing only the user who created the catalog in the first place (the system admin).

So, the current user, although a site collection admin, doesn’t have permissions to read from the app catalog. (This is the weird part, as I expected SharePoint to do the reading using a system account behind the scenes.)

SOLUTION

Add the users that should be able to install your custom apps to the site permissions of the App Catalog site, with Read permission level. In my case it was “Dani Alves” (yes, I’m a Barcelona fan).

Adding Read Permissions to the App Catalog

Now, the app is visible in “Your Apps” when you try to add it to a site. Yeah!Custom App Is Now Visible

Modelo de apps en detalle (IV): Construyendo una app High-Trust

En la última entrega de esta serie de posts sobre el modelo de apps en detalle, hablé de las aplicaciones Low-Trust y aplicaciones High-Trust de SharePoint 2013. Pues bien, hoy vamos a meternos en la harina y hacer una aplicación high-trust (también conocida como S2S, server-to-server) desde cero.

Preparando el entorno

Servicio de perfiles

Para comenzar a crear una aplicación high-trust, necesitamos configurar varias cosas en nuestro entorno local de SharePoint 2013. (Recordáis que las app high-trust sólo se pueden tener en un SharePoint on-premise, ¿verdad?). Las configuraciones no son muchas, pero es fácil olvidarse de una de ellas y luego tendremos problemas para investigar de donde viene el error.

Antes que nada, necesitamos que nuestro SharePoint 2013 tenga activo el servicio de perfiles de usuario y que además tenga indexados los perfiles de los usuarios que vamos a utilizar en la aplicación. Esto es necesario porque el servicio de autenticación de una app high-trust necesita “encontrar” el usuario en el servicio de perfiles de SharePoint para poder ejecutar las consultas en su nombre. Si el perfil del usuario no está, la autenticación fallará.

image

Realmente, el token de acceso que envía la app hacia SharePoint contiene el identificador del usuario, y SharePoint se basa en él para saber si el usuario es válido o no, buscándolo en su base de datos de perfiles. El identificador suele ser el SID del usuario Windows, su UPN o nombre de usuario de Active Directory. Si usamos otros sistemas de autenticación como FBA o Claims, los identificadores serán otros. Es estrictamente necesario que el identificador del usuario esté presente en su perfil y que no haya repeticiones. Si os pica mucho la curiosidad, hay un excelente post de Steve Peschka al respecto.

Certificado SSL

Para poder firmar el token de la app, necesitamos un certificado SSL. Mientras desarrollamos, podemos usar un certificado de desarrollo firmado por nosotros mismos (self-signed certificate). Luego, en producción, usaremos un certificado real.

Además, para que nuestra app se pueda comunicar con SharePoint de manera segura, necesitamos que la comunicación esté encriptada bajo HTTPS. Para ello, necesitaremos otro certificado SSL con la URL de la app. Esto no es necesario en desarrollo, donde podemos relajar la restricción y usar HTTP, pero en producción esto sería una imprudencia seria.

Para crear un certificado autofirmado, iremos a la consola de IIS y bajo el apartado “Server Certificates” y dentro de él la opción “Create Self-Signed Certificate“. Le daremos el nombre CertificadoHighTrust.

imageimageimage

Al final, exportaremos el certificado incluyendo la clave privada. Como contraseña le pondremos “password“. Al final, tendremos un fichero PFX con el certificado digital que usaremos en nuestra app. Este fichero tiene que estar en una carpeta accessible desde Visual Studio. En nuestro caso, como estamos desarrollando en una máquina de SharePoint, no tenemos que mover el fichero y lo tendremos en la ruta C:\Certificates\CertificadoHighTrust.pfx.

imageimage

También haremos una exportación del certificado sin la clave privada, para obtener el fichero CertificadoHighTrust.cer. Para ello, tenemos que ir a “Server Certificates” dentro del IIS, abrir el certificado y en la pestaña “Details” ir a la opción “Copy to file” indicando que no queremos la clave privada.

imageimageimage

Ahora vamos a comprobar los permisos necesarios para que SharePoint pueda procesar nuestros certificados. Los requerimientos son dos:

  • El application pool SecurityTokenServiceApplicationPool tiene que tener permisos de lectura sobre la carpeta de los certificados
  • El application pool de la aplicación web en la que instalaremos la app (en nuestro caso, la del puerto 80) tiene que tener permisos de lectura sobre la carpeta de los certificados

En nuestro caso, son las cuentas SPFarm y SQLSvc. Les daremos los permisos correspondientes en la carpeta Certificates.

imageimage

Ahora tenemos que hacer que SharePoint reconozca nuestro certificado. Abrimos una consola PowerShell de SharePoint y registramos el certificado como de confianza.

image

Configurar trusted issuer

Una vez que SharePoint se fía de nuestro certificado, vamos a proceder a configurar lo que se conoce como un “emisor de confianza“. Esto no es más que indicarle a SharePoint que los tokens firmados por un “emisor de confianza” son de fiar. Y, ¿cómo sabe SharePoint qué un emisor es de confianza? Primero, el ID del emisor (un GUID que va dentro del token) tiene que existir en la configuración de SharePoint. Segundo, el token tiene que estar firmado por un certificado del que SharePoint se “fía” porque tiene su parte pública. Como esta parte del certificado la hemos hecho ya, sólo falta decirle a SharePoint el ID de nuestro proveedor de confianza. Puede ser cualquier GUID, y aquí vamos a utilizar el aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee (si usamos letras en el GUID, tienen que ser en minúscula). Bonito y fácil de recordar, ¿verdad?

Para registrar nuestro emisor de confianza, hay que ejecutar el siguiente código en PowerShell, a continuación del script de importación del certificado:


 

Ya podemos proceder a desarrollar la app, pero antes de esto vamos a permitir el uso del certificado autofirmado relajando los permisos de autenticación. (ojo: esto se puede hacer sólo en los entornos de desarrollo, nunca en producción).


 

Desarrollando la app

La app necesitará el certificado SSL y conocer la contraseña de su parte privada. Además, la cuenta bajo la que se ejecutará la app (el application pool del IIS) tiene que tener permisos para acceder a la ubicación del certificado.

Abrimos Visual Studio 2013 y creamos una app de SharePoint 2013. Al salir el asistente, le indicamos que queremos una app provider-hosted y que la identidad de la app se establecerá mediante certificado.

imageimageimage

Ahora tendremos una aplicación (en mi ejemplo, creada con Web Forms) que muestra el nombre del sitio actual de SharePoint donde está instalada la app. La solución consiste en dos proyectos: el proyecto de la app de SharePoint y el proyecto web donde está la lógica de la app.

image

El código que hace la llamada a SharePoint es muy sencillo:


 

 

Como se puede ver, el contexto de SharePoint se establece usando la clase auxiliar TokenHelper con el método GetS2SClientContextWithWindowsIdentity. Esta llamada obtiene un contexto de high-trust app (S2S, server-to-server) usando la identidad del usuario Windows que está ejecutando la aplicación. Esta es la configuración por defecto, pero se puede modificar para usar la identidad federada por ejemplo.

Ejecutando la aplicación, nos sale el diálogo de otorgar permisos a la aplicación, y al aceptarlo, podemos ver el título del sitio de SharePoint, “Home”.

imageimage

Dentro del TokenHelper

Vamos a ver como nuestra aplicación construye el token. Si miramos el método GetS2SClientContextWithWindowsIdentity, veremos que su cuerpo tiene 4 lineas de código.

Primero se obtiene el dominio (realm) de la aplicación. Acto seguido se obtiene un JWT (JSON Web Token) que contiene los claims del usuario actual de Windows. Una vez que tenemos el token JWT, lo empaquetamos en un token de acceso con el método GetS2SAccessTokenWithClaims. Al final, el token de acceso lo intercambiamos por un contexto cliente de SharePoint.
La parte interesante es ver como se hace el token. Si miramos el método GetS2SAccessTokenWithClaims, veremos que acaba en un método IssueToken, que está construyendo el token de acceso.

 

El siguiente artículo de MSDN explica las partes del token de acceso que construye nuestra aplicación. En esencia, se construye un token de “actor” que identifica el usuario actual. Este token de actor se hace con los claims del usuario creados previamente. El token se expide para la aplicación actual (parámetro “aud“) y lo firma nuestro certificado (propiedad SigningCredentials). Este token interno se rodea de un token externo que no está firmado digitalmente.
Como se puede ver, el misterioso “token de acceso” es nada más que una cadena de texto con datos en formato JSON que describen una identidad de aplicación y de usuario.
La última parte “misteriosa” es saber como obtiene SharePoint el objeto ClientContext a partir de un token? Es muy sencillo: adjunta el token de acceso en la cabecera de la petición a la API, y al volver ya estará inicializado correctamente el contexto. Ahora lo veremos con Fiddler.

Las pruebas con Fiddler

Si abrimos Fiddler para ver el tráfico HTTP entre la aplicación y SharePoint, veremos que la aplicación hace una llamada a la API CSOM (/_vti_bin/client.svc/ProcessQuery). Si miramos la petición, en las cabeceras veremos un parámetro llamado Authentication con el valor “Bearer: ” seguido de un texto codificado en Base64. Este es nuestro token de acceso.

image

Si usamos alguna herramienta como JWT.io para descodificar el token, podemos ver su estructura.

image

Para más información sobre la estructura del token, hay un magnífico post de Kirk Evans al respecto.

Conclusión

Espero haber desmitificado un poco el mundo de las aplicaciones High-Trust con este post. Como veréis, nos permite usar el modelo de apps sin tener que estar en la nube, lo que es un paso importante para poder adaptar nuestros desarrollos a los escenarios híbridos que parece que serán mucho más habituales en el futuro.

¿Habéis trabajado con este modelo? ¿Podéis compartir vuestras experiencias? ¡Los comentarios os esperan aquí mismo, debajo de este post!

Apps de SharePoint vs Apps de Office 365

En estos últimos días hay un debate calentito sobre el futuro del modelo de apps de SharePoint.

El día 22 de diciembre el gran gurú SharePointero Sahil Malik publicó el siguiente post (SharePoint App Model: Rest in Peace) que abrió un poco la caja de Pandora sobre el modelo de las apps. Su argumento es que el modelo de las apps introducido con SharePoint 2013 está quedando arrinconado a favor del nuevo modelo de apps de Office 365.

Veamos un poco en detalle este debate. Primero voy a presentar a los boxeadores y luego veremos como queda el match.

image

Los contrincantes en el ring

El modelo de apps de SharePoint 2013

Ya llevamos unos años con este modelo, que todavía se usa bien poco para los proyectos "serios". En esencia, tenemos a SharePoint como proveedor de datos y una aplicación remota (provider-hosted) o JS consumiendo esos datos mediante interfaz REST (o su abstracción JSOM/CSOM). Para la autenticación entre la aplicación remota y SharePoint se usan los tokens OAuth, con la posible intermediación de Azure ACS.

Apps for SharePoint hosting options

El modelo de apps de Office 365

Este nuevo modelo introducido en 2014 es una abstracción por encima de los servicios de la plataforma de Office 365. Los servicios se exponen mediante la interfaz REST y están pensados para proporcionar operaciones de alto nivel como "obtener contactos" o "leer documentos". Las aplicaciones pueden hacerse en cualquier tecnología y para autenticar la aplicación con Office 365 se dispone de Azure Active Directory (AAD) que almacena las credenciales de los usuarios y nos devuelve sus tokens para usarlos contra la API de Office 365.

Development stack for creating solutions that use Office 365 APIs. Select your developer environment and language. Then use Azure single sign-on authentication to connect to the Office 365 APIs.

¿En que se diferencian?

En muchas cosas, pero en mi opinión las diferencias básicas son:

Apps de SharePoint

Apps de Office 365

Operaciones de bajo nivel

Operaciones de alto nivel

Usan Azure ACS

Usan Azure AD

Sólo pueden acceder a SharePoint

Pueden acceder a los servicios de O365, Azure Active Directory y a SharePoint

Permiten el modelo high-trust para instalaciones "on premise"

Sólo se puede usar con la instalación cloud o híbrida

 
Si queréis ver una comparativa muy bien ilustrada con pantallazos, este post de Chris O’Brien es el mejor recurso.

Entonces, ¿qué hago?

Visto este percal al que Microsoft nos ha llevado, uno se puede preguntar sobre que esperar en el futuro. ¿Desaparecerá el modelo de las apps en la siguiente versión de SharePoint como ya pasó con las aplicaciones sandbox? Si voy a hacer una app para SharePoint, ¿uso el modelo SharePoint o el de Office 365?

Yo creo que el modelo de las apps de SharePoint 2013 no desaparecerá, sino que será uno más a considerar. Ahora tenemos el modelo Full-trust code (FTC) de toda la vida, soportado 100% on-premise, modelo de apps soportado en el cloud y on-premise y en la nueva versión de SharePoint tendremos la opción de usar el modelo de apps de Office 365, si tenemos un despliegue en la nube o híbrido. Lo que no vamos a ver es "un modelo que los gobierne a todos". Al abrirse el abanico de opciones de hospedaje de SharePoint, Microsoft ha abierto el abanico de soluciones de código a medida para encajar mejor en cada uno de ellos.

El modelo de apps de Office 365 es más limpio que el de apps de SharePoint, pero es comprensible dada su naturaleza. Es un modelo abstracto de servicios sobre toda la plataforma Office 365 y no tiene que preocuparse de detalles técnicos como las insufribles páginas AppRegNew.aspx, ClientIds y tonterías varias. Si estamos haciendo una app empresarial que combina la gestión de documentos, listas, contactos, mails etc., el modelo de Office 365 es más directo y fácil.

El modelo de apps de SharePoint lo veo más bien enfocado a las soluciones que sólo involucren a SharePoint o cuando no estamos en el mundo Office 365, ni siquiera en modo híbrido. Igualmente, si sabemos lo que hacemos y quedemos toda la potencia de SharePoint para nosotros en nuestro datacenter, el modelo de código de servidor no va a desaparecer.

Y vosotros, ¿qué opináis?

High-Trust SharePoint Apps, Token Lifetime and MemoryCache

In the last months I have been busy working on a project that includes high-trust on-premises SharePoint 2013 app that is accessed by many people at the same time. Each user is issued an access token that authenticates the user and points to his or her SharePoint site.

The problem that began surfacing is that by default high trust access tokens have a lifetime of only 10 minutes. So, as we cached the token in memory, after 10 minutes SharePoint would start giving 401 Unauthorized errors, due to the token being expired.

Extending the lifetime of the access token

The solution to the problem involved increasing the lifetime of the access token to 60 minutes. This is a fairly simple change in TokenHelper.cs file.

Find the IssueToken private method in TokenHelper.cs and in the "Outer Token" region, change the line that creates the JWT token to this:

MemoryCache

In addition, we have added a MemoryCache single instance in-memory application cache (available in NET 4.5). The access tokens are added to the cache with an absolute lifetime of 60 minutes, so they will expire at the same time as their lifetime in SharePoint. Once evicted from the memory cache, the access tokens are recreated with an additional 60 minutes of lifetime and stored in the cache again.

Bonus: Refactored for reusability and testing

In order to make our code simpler and more understandable, we added the caching capability as a provider, exposed by the ICachingProvider interface. The ICachingProvider interface exposes the operation for getting an object from the cache with a specific key. We wanted the code to be reusable not only for tokens but for all suitable situations.

The operation GetFromCache is a generic method that allows the user to get a typed object from the cache by providing a string key and a type. Moreover, the operation requires a fallback method. This fallback method is a generic Func<T> that returns an object of type T. The cache implementation then uses the function delegate (a lambda expression, in most cases) if the specified key is not found. By invoking the delegate, we get the object from its source (as if there were no cache) and store it in the cache with the given key.

The full CachingProvider code is displayed here. There are two auxiliary methods to add and retrieve items from the cache. In order to avoid concurrency exceptions, the access to the MemoryCache instance is protected under a lock object called padLock.

One added bonus of having an interface is that we had two implementations of the interface: CachingProvider (the normal caching service) and DummyCachingProvider (that simply bypassed the cache and returned the result of the Func delegate invocation). In this way we could disable caching by injecting the correct instance of the caching provider and also it benefitted unit testing as we could test both the cached and non-cached code paths.

Modelo de apps en detalle (III): High-Trust

En los primeros dos posts de esta serie hemos visto la evolución del código personalizado en SharePoint y la arquitectura básica del modelo de apps. También hemos visto a grandes rasgos como la app se autentica con SharePoint utilizando Azure Access Control Service (ACS) como intermediario.

Las apps en SharePoint Online funcionan con este método de autorización de las apps, llamado low-trust.

Modelo Low-Trust: SharePoint + app + ACS

En este modelo, SharePoint es el responsable de pasar un token de contexto a la app, cuando hace la redirección a ella. La app valida el token de contexto y lo intercambia por un token de acceso, haciendo una llamada a ACS. Fijaos que el modelo low-trust deja a la app como un mero transmisor de tokens entre SharePoint y ACS. Por eso mismo se llama de "baja confianza". La app no puede añadir ni quitar nada de la información de autenticación y autorización. Todo esto viene dado en el token inicial que se le pasa a la app desde SharePoint.

Este modelo es muy útil para apps públicas sobre las que no tenemos ningún control. Por ello es el modelo usado para la SharePoint Store y las apps disponibles en SharePoint Online. En los entornos on-premise corporativos, este modelo requiere dar conectividad a Internet a los servidores de SharePoint y los servidores de las apps así como establecer una relación de confianza entre SharePoint on-premise y el servicio ACS de Azure.

Modelo High-Trust: SharePoint + app

En los entornos corporativos on-premise de SharePoint, podemos usar otro modelo de autorización y autenticación de las apps, en el que SharePoint establece una relación de confianza con la app y delega en ella la autenticación del usuario. Este modelo es el llamado high-trust o de alta confianza. También se le llama S2S (Server-to-Server).

No hay que confundir el modelo de high-trust con full-trust. Full-trust es el código personalizado de servidor de SharePoint que desplegamos en la GAC, y por lo que tiene todos los permisos que tiene SharePoint. Una app high-trust tendrá como mucho los permisos que se le han otorgado durante su instalación, ni más ni menos, idéntico al caso de las low-trust apps.

Entonces, ¿por qué se llama "de alta confianza"? Es así debido a que no hay un intermediario (como ACS) y que SharePoint se fía de la app para que le construya el token de acceso adecuado.

Para que el modelo high-trust funcione, tenemos que habilitar una relación de confianza entre la app y SharePoint. Esto se consigue utilizando un certificado digital. La parte pública de este certificado se registra en SharePoint como "trusted token issuer" o emisor de tokens de confianza. En el caso de las low-trust apps, el único "emisor de tokens de confianza" es el ACS. La parte privada del certificado se usará en la app para firmar los tokens emitidios por ella.

Al ser la app un emisor de tokens de confianza, SharePoint aceptará los tokens que ella misma construya. Previamente los validará con la clave pública del certificado, lo que comprueba que no han estados modificados durante el tránsito. Luego, aplicará los permisos que tiene la app en SharePoint (que se le han dado al instalarla) e incluirá la información del usuario actual (que está contenida en el token de acceso que construye la app).

Fijaos que la app puede construir el token de acceso para cualquier usuario. Esta es la parte en la que nos tenemos que "fiar" de la app. Sin embargo, el ámbito de actuación de la app está limitado a los permisos que se le han dado al instalar, así que aunque la app puede "falsear" la información del usuario (como decir que viene de parte de la cuenta del sistema), como mucho puede hacer lo que se le permite a la app, sin poder saltárselo.

Vayamos a ver el "baile" de conversación entre SharePoint y una app high-trust al abrir la app desde el navegador.

image

  1. El usuario abre una página de SharePoint y clica en el enlace de la app.
  2. SharePoint hace la redirección a la URL de la app (respuesta 302 de HTTP). No incluye ningún token de contexto (como en el caso de las low-trust apps).
  3. El navegador realiza la petición a la URL de MiApp.com como respuesta a la redirección.
  4. La aplicación recibe la petición HTTP. Para acceder a SharePoint mediante CSOM o REST, la aplicación necesita un token de acceso. La aplicación construye el token de acceso y lo firma con la clave privada de su certificado. Incluye este token en la petición a SharePoint.
  5. SharePoint comprueba la validez del token de acceso con la clave pública del certificado de la aplicación y devuelve los datos que la aplicación le ha pedido.
  6. La aplicación renderiza el HTML que se va a visualizar y lo devuelve al navegador.

Construyendo los tokens de acceso

La misma clase auxiliar TokenHelper.cs que usamos en las apps de ASP.NET contiene los métodos para construir los tokens de acceso de high-trust apps. Si miramos el código fuente del mismomiramos el código fuente del mismo, veremos dos métodos:

  • GetS2SAccessTokenWithWindowsIdentity
  • GetS2SClientContextWithWindowsIdentity

El primer método devuelve un token de acceso para un usuario concreto, firmado con la clave privada del certificado de la app. El segundo devuelve un contexto de SharePoint CSOM (ClientContext) inicializado para un usuario concreto.

El usuario se le pasa como parámetro al método, y es una instancia de WindowsIdentity. Internamente, la clase TokenHelper convierte este usuario en un conjunto de claims y construye el token con estos claims. Este detalle de implementación obliga a que la app esté alojada con la autenticación Windows habilitada, ya que sin ella la app no podría obtener una instancia de WindowsIdentity. Sin embargo, es posible cambiar la clase TokenHelper para que expida tokens con un ClaimsIdentity (identidad procedente de claims) si usamos ADFS o algún otro proveedor de identidad (STS) compatible con credenciales SAML. Lo veremos en uno de los próximos posts.

Pero, ¿cómo sabe TokenHelper donde está el certificado para firmar? Bueno, se lo tenemos que decir nosotros usando el fichero web.config. Hay que añadir unas entradas adicionales, a parte de las obligatorias para la app (como el ID de la app y su URI), especificando una ruta de certificado y una contraseña para firmar con la clave privada. Además, el application pool de la app tiene que tener permisos suficientes sobre la carpeta donde se halla el certificado.

Resumen

Hemos visto como las apps high-trust simplifican la autorización y autenticación en un entorno on-premise. En el próximo post veremos como configurar un entorno de SharePoint on-premise y haremos una app high-trust desde cero.

Modelo de apps en detalle (II): Las piezas

En el primer post de esta serie sobre el modelo de apps de SharePoint 2013, expliqué la problemática de tener código a medida en SharePoint y como SharePoint ha evolucionado para acomodarla, hasta llegar al modelo de apps en SharePoint 2013.

En este segundo post voy a explicar las piezas clave del modelo de apps, para asentar los conocimientos básicos antes de meternos en detalle con la autorización y la autenticación de la app.

Los "webs" del modelo de apps

A grandes rasgos, el modelo de apps involucra tres piezas básicas en forma de sitio web:

  • "host web" (SharePoint)
  • "app web" (SharePoint)
  • "remote web"

Voy a poner un diagrama completo de las piezas de las apps y lo comentaremos a lo largo de este post. Entender bien estas piezas y su relación es tener la mitad del trabajo hecho. Vayamos por partes.

image 

Host Web

Las apps se instalan en un sitio de SharePoint y se lanzan desde allí. Ese sitio web, en el que la app está instalada y tiene ciertos permisos, se llama host web.

App Web

Una app al instalarse puede crear un sitio de SharePoint para su propio uso. Este sitio, si existe, se llama app web y tiene la URL con un dominio diferente al de host web. Esto se hace para impedir llamadas cross-site de JavaScript.

¿Para qué nos sirve un app web? La idea es guardar aquí los datos propios de la app, como los resultados parciales, configuraciones, perfiles de usuarios etc. La app web es invisible para el usuario normal de SharePoint, y no se puede acceder a ella mediante la interfaz de usuario.

Remote Web

Para las aplicaciones provider-hosted (es decir, las que tienen código y no sólo JavaScript), la invocación de la app tiene forma de redirect hacia una URL en la que está alojada la aplicación. Este sitio donde está alojada la app se llama remote web. Lo más probable es que la app esté alojada en un IIS (on-premise o en Azure) pero podría estar alojada en cualquier tecnología web (Apache, Linux, Node.js…). Sin embargo, si usamos ASP.NET como la plataforma para la app, se nos simplifica la comunicación con SharePoint ya que disponemos de librerías y helpers.

Los permisos

Pongamos como ejemplo que acabamos de clicar el enlace de la app en SharePoint, concretamente en http://contoso/site1. . Como ya sabéis, esto implica que la app está instalada en http://contoso/site1, que es la host web de la app.

La app también tiene ciertos permisos sobre la host web, que se le otorgan al instalarla. Los permisos pueden ser de leer algunas listas de la host web hasta tener control total sobre la tenancy o la site collection en la que está la host web. Los permisos de declaran en el paquete de la app (que veremos más adelante) y la persona que instala la app tiene que tener la potestad de otorgarlos.

Resumiendo, la app tiene los permisos sobre la host web que le hayamos dado al instalarla. Ni uno más ni uno menos.

Si la app dispone de una app web (que es otro de los parámetros que podemos poner en el paquete de la app), la app tiene el control total sobre la app web. Puede hacer y deshacer lo que le dé la gana. Como la app web no se muestra al usuario y sirve como un mero repositorio de datos para la app, no hay peligro en darle control total sobre esa parte de SharePoint.

Para nuestro ejemplo, imaginemos que la app web tiene la url http://app123.contosoapps.

La comunicación entre SharePoint y la app

Volvamos al ejemplo. Hemos clicado la app en http://contoso/site1 y nos ha llevado a https://wingtip/app1/start.aspx. Esta URL es parte del paquete de la app, y es la que lleva a la remote web de la app. En este caso, imaginemos que https://wingtip/app1 es un sitio IIS en una máquina dentro del datacenter de Contoso. Una máquina que no tiene ni idea de SharePoint y que contiene una app hecha en ASP.NET WebForms.

ASP.NET carga la página start.aspx. En este momento la app tiene que establecer la conexión con SharePoint para cargar los datos que necesita de allí. Veamos como lo hace.

Lo primero que necesita la app en remote web es saber a qué URLs tiene que llamar para obtener los datos de la host web y la app web.

¿Cómo lo sabe? Podríamos guardar estas URLs en la configuración de la app (en web.config o en la base de datos) pero lo más habitual es que al llamar la app desde SharePoint se incluyan estas URLs en la URL con la que se llama a la app. Así, nuestra app no se llama con un redirect a https://wingtip/app1/start.aspx sino a https://wingtip/app1/start.aspx?SPHostUrl=http://contoso/site1&SPAppWebUrl=http://app123.contosoapps. Como podéis ver, en los parámetros SPHostUrl y SPAppWebUrl tenemos las URLs de la host web y de la app web, respectivamente.

image

Usando el modelo de objetos de cliente de SharePoint podríamos instanciar un contexto a través de esas URLs, pero nos faltaría la autenticación. Es decir, ¿con qué credenciales de usuario abrimos el contexto de SharePoint? Vamos a ver como lo resuelve el modelo de apps.

Autenticación de la app

En el primer post de esta seria dije que las apps de SharePoint 2013 tienen identidad propia y se les pueden asignar permisos. Pues este es el mecanismo con el que se resuelve el problema de las credenciales: el contexto de SharePoint se abrirá con las credenciales de la app.

¿De dónde vamos a sacar las credenciales de la app? Esto depende de si estamos usando las apps en SharePoint Online o una granja on-premise federada con Azure Access Control Service (ACS) o bien estamos usando las apps en un entorno on-premise con certificados.

El primer caso es el más frecuente y se llama "low-trust" (baja confianza). En este caso, SharePoint usa un servicio de Azure llamado ACS (Access Control Service) para confimar la identidad de la app. ¿Cómo? Pues sencillamente antes de hacer el redirect a la app, inyecta en la cabecera de la petición HTTP un pequeño fragmento de texto, un token de contexto, que le servirá a la app luego para sacar las credenciales.

image

Este token de contexto contiene la información sobre la identidad de la app. La app (ASP.NET) tiene que extraer este token de la petición inicial HTTP, hacer una petición a ACS e intercambiarlo por otro token, llamado token de acceso. El token de acceso nos sirve para instanciar un contexto de SharePoint, ya que es un token OAuth que SharePoint 2013 acepta. Este token se incorpora en la cabecera de la petición a la interfaz REST de SharePoint 2013 con el nombre de "Bearer".

image

Podéis ver el contenido exacto de los tokens de contexto y acceso en el siguiente enlace: http://msdn.microsoft.com/library/office/fp179932.aspx#Tokens.

Todo este proceso de extraer los tokens, validarlos, intercambiarlos y crear el contexto de SharePoint está encapsulado en una clase autogenerada por Visual Studio al hacer una app de SharePoint, que se llama TokenHelper.cs. Podéis examinarlo y ver como hace la petición a ACS y que luego incorpora el token de acceso para llamar a SharePoint.

Si estamos en una plataforma que no es .NET (como PHP por ejemplo), podemos hacer el mismo proceso pero no tendremos un TokenHelper mágico. Tendremos que hacer la extracción y construcción de tokens y de llamadas a ACS de manera manual, pero no hay nada intrínsecamente difícil en ello.

Resumiendo

Como podéis ver, el "baile" entre las piezas de las apps es delicado y hay muchos conceptos involucrados. Os recomiendo releer este post hasta que os quede claro la interacción entre host web, app web y remote web, así como el papel de los tokens. Si queréis más detalles sobre los tokens y la autenticación low-trust, os recomiendo el artículo siguiente de Kirk Evans del equipo de SharePoint (en inglés): http://blogs.msdn.com/b/kaevans/archive/2013/04/05/inside-sharepoint-2013-oauth-context-tokens.aspx.

En el siguiente post veremos como las aplicaciones "high-trust" resuelven el problema de la autenticación sin delegarlo a un servicio de terceros como ACS.

Modelo de apps en detalle (I): Introducción

Hola a todos,

En un reciente proyecto me he visto involucrado en mucho detalle en el modelo de apps de SharePoint 2013 en entornos corporativos, con aplicaciones de alta confianza (high-trust) y autenticación federada con Claims. Mi idea en esta serie de artículos en el blog es compartir estos conocimientos ya que creo que existe poca información de primera mano sobre la utilización real del modelo de apps, fuera de las apps de demostración.

En este primer post voy a recordar la evolución del modelo de programación de SharePoint.

Antes de SharePoint 2010

Para un programador "veterano" en SharePoint, la programación en SharePoint siempre implica poner el código NET en el servidor de SharePoint. Desde que SharePoint abrazó el modelo de programación NET en la versión 2003, siempre ha sido así. El código de nuestras soluciones SharePoint se pone en la carpeta BIN de la aplicación web de SharePoint o bien en la GAC del servidor.

image

Los beneficios de este enfoque son el acceso a toda la potencia del modelo de objetos de SharePoint de servidor (Server Object Model) y de NET. Sin embargo, nos exponemos a que nuestro código ralentize el servidor (ya que se ejecuta en el mismo proceso que el código propio de SharePoint) y a que tengamos que preparar bien las actualizaciones de SharePoint. Solo hay que recordar las migraciones de una versión de SharePoint a otra y la caza y captura de código a medida para actualizarlo al nuevo modelo.

La raíz del problema es que SharePoint "puro" sin código a medida tiene un rendimiento muy bueno y que SharePoint con código a medida que no esté bien optimizado (y la verdad es que la mayoría del código a medida en SharePoint que circula por ahí no lo está) puede castigar el rendimiento de tal manera que no sea usable. En esencia: no hay nada que nos impida "frenar" a SharePoint con nuestro código lento. (como ejercicio podéis poner una webpart en SharePoint que haga un Thread.Sleep(5000) y SharePoint se volverá 5 segundos más lento).

SharePoint 2010: CSOM y Sandboxed

Para solventar de alguna manera este acoplamiento fuerte entre SharePoint y nuestro código, en SharePoint 2010 aparecen dos componentes arquitectónicos nuevos.

En primer lugar, tenemos un modelo de objetos de cliente (Client-side Object Model, CSOM) disponible en NET, Silverlight y JavaScript. De esta manera podemos crear código que se ejecute fuera de SharePoint. El modelo de objetos de cliente no es tan potente como el modelo de objetos de servidor, pero es usable en muchos escenarios comunes.

En segundo lugar, aparece el concepto de código sandboxed. Por primera vez, el código a medida se puede ejecutar en un proceso separado de SharePoint y por tanto sometido a restricciones de tiempo de CPU y memoria. De esta manera podemos mantener estable el entorno propio de SharePoint y protegerlo de cierta manera de nuestro código potencialmente acaparador de recursos.

modelo_sandbox

Las aplicaciones sandboxed prometían lo mejor de los dos mundos: acceso al modelo de objetos de servidor y a la vez un control sobre el uso de recursos del código que lo utiliza.

SharePoint 2013: Cloud-based Apps (CBA)

¡Y llegó SharePoint 2013! De buenas a primeras, se cargó de un plumazo "deprecador" el modelo sandbox que tanto prometía. Para sustituirlo, optó por desterrar el código a medida fuera del servidor de SharePoint en el nuevo modelo de apps (cloud-based applications, CBA).

Por tanto, el modelo de desarrollo preferente en SharePoint 2013 es tener todo el código fuera de SharePoint (en apps) y puesto en otro proceso que potencialmente esté en otra máquina así como utilizar el modelo de objetos de cliente (ya introducido en SharePoint 2010) para interactuar con los datos en SharePoint. De esta manera se cumple el objetivo importante de no que el código a medida lento no haga lento a SharePoint, pero a costa de tener que utilizar una API de cliente incompleta y que no está a la par del modelo de objetos de servidor.

modelo_apps

Para que el código a medida de las apps pueda llamar a SharePoint sin tener en cuenta el usuario concreto, se adaptó el estándar OAuth para crear las credenciales de las apps. En SharePoint 2013 una app tiene una identidad propia y permisos propios. En tiempo de ejecución, se combinan los permisos de la app y los permisos del usuario que utiliza la app para determinar los permisos efectivos.

Cuando apareció el modelo de las apps, había 3 "sabores" de las mismas: SharePoint-hosted, auto-hosted y provider-hosted. En junio de 2014 desapareció la opción auto-hosted. Las apps SharePoint-hosted sólo pueden contener código JavaScript así que para las aplicaciones corporativas son más bien inútiles. Esto nos deja con el modelo provider-hosted como el único realmente utilizado para hacer una app de cierta relevancia en SharePoint 2013.

Resumen

En este post hemos revisado la evolución de los modelos de desarrollo a medida de SharePoint, hasta el modelo de apps de SharePoint 2013. En el post siguiente abordaré el modelo de las apps en detalle para explicar las piezas que lo componen e ir introduciendo el concepto de low-trust y high-trust apps. ¡Hasta pronto!

Las apps de SharePoint 2013 (V): Una app provider-hosted en Azure

En la serie de posts sobre el desarrollo de apps de SharePoint 2013, hemos visto hasta ahora un ejemplo de app de SharePoint 2013 para niños alojada en SharePoint mismo y otro ejemplo de app alojada “automágicamente” en Azure. Ahora falta una vuelta de tuerca más para ver el modelo que nos queda: las llamadas aplicaciones provider-hosted.

Si recordamos los tres modelos de alojamiento de apps que hay en SharePoint 2013, las aplicaciones provider-hosted requieren intervención manual para que SharePoint y la parte servidora se hablen entre ellos. En el caso de Azure esto se reduce bastante porque las herramientas de SharePoint y de Azure nos lo facilitan, pero si hacemos una subida a la nube de Amazon o a nuestro propio datacenter, la cosa se nos hace un poquito más engorrosa, sin llegar a ser difícil en ningún caso.

El punto de partida

Vamos a empezar con la aplicación desarrollada para el modelo autohosted en Azure, para ir más ágiles y para seguir usando ASP.NET MVC (que es lo que mola ahora).

image

La vamos a subir “manualmente” a Azure Web Sites y le vamos a decir a SharePoint que se conecte a ella cuando el usuario clica la app.

Nota: A los que ya conocéis Azure y pensáis que estoy mostrando solo la parte “express”, os comento que estoy dejano para una próxima entrega de la serie de posts una app totalmente “Azure” que use servicios más avanzados como Storage, SQL Azure etc.

Configuración de Azure

El primer paso es ir a nuestro panel de control de Azure (o darnos de alta en la prueba gratis de Azure de 90 días y luego ir al panel de control). Allí crearemos un sitio web de Azure, sencillo, y usaremos los detalles del sitio para configurar el proyecto MVC en Visual Studio.

Iremos a la opción Sitios Web y crearemos uno nuevo con el nombre EdinSpMvc-Provider.

image

Esperamos unos momentos y el sitio se habrá creado correctamente

image

Ahora vamos a clicar la flecha al lado del nombre del sitio web para ver el panel de control del sitio y descargaremos el perfil de publicación (en Vista Rápida) para usarlo en Visual Studio más adelante.

image

Creación de la app en SharePoint

Ahora iremos a nuestro sitio en SharePoint 365 Developer Site (en mi caso es https://edinkapic.sharepoint.com/sites/dev). Tenemos que hacer un “truquillo” para registrar una app manualmente: añadiremos a la URL del sitio el sufijo /_layouts/15/appregnew.aspx.

Se nos abre la ventana de registro de una nueva app.

image

Esta es “la madre del cordero” que enlaza SharePoint con nuestra app. Explicaré los conceptos que tenemos que introducir (para más detalles está la MSDN):

  • App Id: esto es un Guid que identifica la app de manera única. Generaremos uno al azar dándole al botón Generar.
  • App Secret: esto la parte pública de una clave asimétrica que usa SharePoint para validar que nuestra app tiene permisos para conectarse. Nuestra app en MVC se conectará a SharePoint pasándole la este secreto junto con más parámetros y SharePoint comprobará que es efectivamente la app que él autorizó. Generaremos una al azar dándole al botón Generar.
  • Title: El título de la app. Pondremos App Provider-Hosted en Azure y MVC
  • App Domain: aquí irá el dominio de nuestro hosting (Azure Web Sites). Pondremos edinspmvc-provider.azurewebsites.net
  • Redirect URL: aquí pondremos la página de inicio de nuestra aplicación MVC, en nuestro caso https://edinspmvc-provider.azurewebsites.net/Home. Es imprescindible poner HTTPS (en Azure no tenemos que preocuparnos porque automáticamente tenemos HTTPS en Web Sites, pero si lo subimos a otro hosting tenemos que asegurarnos de que disponga de HTTPS habilitado).

image

Le damos a Create y nos aparecerán los detalles una app que lamentablemente no será funcional porque todavía no hemos subido nada a Azure. Apuntamos estos detalles para más adelante.

image

Intercambio de cromos

Ahora nos toca retocar un poco nuestra solución en Visual Studio para pasar estos datos de la app manualmente a nuestros proyectos.

En el proyecto de SharePoint App (EdinSpMvc)

Primero vamos a cambiar el tipo del proyecto de app de SharePoint 2013 de Autohosted a Provider-hosted. No hay ninguna UI para hacerlo, pero afortunadamente editando el AppManifest.xml lo podemos conseguir. Sólo hay que:

  • Eliminar la sección AppPrerequisites
  • Reemplazar el elemento AutoDeployedWebApplication dentro de AppPrincipal por <RemoteWebApplication ClientId="508e1afa-40d8-4e2b-99dc-7604460cf864" />. Si habéis prestado atención, es el AppId que nos ha generado SharePoint para la app.
  • Sustituir la URL en el elemento StartPage por la URL completa del sitio, quedando así: https://edinspmvc-provider.azurewebsites.net/Home?{StandardTokens}

image

En el proyecto web MVC (EdinSpMvc4Web)

Aquí tenemos que añadir los valores reales de AppId y AppSecret dentro del fichero web.config (en los elementos ClientId y ClientSecret):

image

Ahora procederemos a subir el proyecto web a Azure. Para ello haremos botón derecho en el proyecto web, clicar Publish y en la pantalla que se nos abre elegir el fichero que previamente descargamos de Azure.

imageimage

Le damos a Publish y veremos que Visual Studio sube nuestra app a Azure y la abre. No os preocupéis que esté dando errores al abrirse, es normal porque le falta el contexto de app de SharePoint.

image

Aún nos queda un pequeño paso: meter el AppId y AppSecret otra vez en Azure ya que al subir la web se “pierde” el valor de los appSettings. Para ello hay que ir a la pantalla de gestión de Sitios Web de Azure y en el enlace Configuración de nuestro sitio añadir las dos entradas idénticas a las del web.config. ¡No os olvidéis de darle a Guardar en la botonera inferior!

image 

Pasos finales y el resultado

Ahora podemos hacer un Deploy de la solución desde Visual Studio 2012 y ocurrirá la magia, esta vez con un poco más de preparativos que la última vez.

imageimage

Como es habitual, os dejo el código de esta aplicación en mi cuenta de SkyDrive.

¡Hasta la próxima entrega!

Las apps de SharePoint 2013 (IV): Una app en MVC y en Azure

En la serie de posts sobre el desarrollo de apps de SharePoint 2013, hasta ahora hemos visto como se desarrolla una app sencilla y alojada en SharePoint (es decir, las “SharePoint-hosted” apps). Ahora vamos a subir un poco la dificultad (no mucho, os lo prometo) y vamos a hacer una app que se ejecuta fuera de SharePoint.

Para que el ejemplo sea más interesante, vamos a hacerlo en un “sabor” de ASP.NET al que no estamos tan acostumbrados los SharePointeros: ASP.NET MVC 4. Como la app fuera de SharePoint puede estar escrita en cualquier lenguaje que se nos antoje, usaremos MVC 4 para aprovecharnos de la librería de modelo de objetos de cliente de SharePoint 2013 (CSOM) y ahorrarnos trabajo.

SharePoint 2013 y Azure

En estos momentos Microsoft ofrece una cuenta de desarrollador de Office (incluyendo SharePoint) gratis si nos apuntamos en este enlace. Con ello se nos dará un sitio en Office 365 Preview (es decir la versión 2013) ya preparado para alojar apps de SharePoint 2013. Además, se nos dará una cuenta “invisible” en Azure para nuestras apps. Digo que es invisible porque no hay manera (de momento) de gestionar la suscripción para estas apps.

image

Para las apps que se consideran “Autohosted”, Visual Studio 2012 con las herramientas de SharePoint va a hacer una doble función:

  • Si estamos desarrollando y le damos a F5, VS2012 va a subir el descriptor de nuestra app a la cuenta de Office 365 de desarrollador (esto lo configuramos nosotros en el proyecto de app) pero la apuntará a nuestro localhost donde se ejecutará el proyecto web de ASP.NET que contiene la lógica de la app.
  • Si hacemos un Deploy de la solución, VS2012 subirá el descriptor de la app a Office 365 (como antes) pero además subirá el proyecto web a un subdominio de o365apps.net, que es una suscripción especial de Azure Web Sites disponible a nosotros como desarrolladores de la app. El subdominio será un GUID creado de manera automática al deployar la app. Además, va a cambiar el descriptor de la app para que apunte a Azure y no a nuestro localhost.

Vale la pena recalcar que la suscripción “invisible” de Azure para apps de Office/SharePoint sólo incluye Web Sites (un hosting de IIS, vamos) y SQL Azure (mediante scripts), sin incluir nada de Media Services, Mobile Services, Storage, Compute y otras maravillas de Azure.

La app en Azure y MVC, paso a paso

Para que todo esto resulte más fácil de digerir, vamos a hacer un pequeño ejemplo que muestre las listas y bibliotecas que hay en el SharePoint donde está alojada la app. Lo codificaremos en MVC 4 y lo “subiremos automágicamente” a Azure. El prerrequisito es, como siempre, tener instaladas las herramientas de desarrollo de SharePoint 2013 con Visual Studio 2012 y tener la suscripción de desarrollador de Office 365.

Abrimos Visual Studio 2012 como Administrador y creamos un proyecto nuevo de Aplicación de SharePoint 2013. Le decimos a VS2012 que la app es de tipo Autohosted y le pasamos la URL de nuestro Developer Site de Office 365.

imageimage

Visual Studio creará dos proyectos: el de la app (EdinSpMvc, poco más que un manifest) y el proyecto ASP.NET WebForms (EdinSpMvcWeb) con la parte de la app que se ejecuta fuera de SharePoint. Como podéis ver, contiene una página Default.aspx de toda la vida.

image

Como esta basura tecnología no nos interesa, vamos a agregar otro proyecto web, esta vez una aplicación web de MVC 4. Es importante seleccionar NET Framework 4 en vez de 4.5 que nos sale por defecto, ya que el Azure que nos da Office Developer no tiene todavía soporte para NET 4.5. A continuación, elegimos Basic como plantilla por defecto de la aplicación MVC.

imageimage

Ya tenemos 3 proyectos: el de la app, el de web ASP.NET y el de web MVC 4.

image

Vamos a configurar el proyecto web MVC con algunos detallitos para que funcione bien con SharePoint 2013. Tenemos la suerte de que las herramientas de VS2012 ya lo hacen automáticamente por nosotros.

Primero, vamos a las propiedades del proyecto de app de SharePoint para asociar el proyecto web MVC en la propiedad Web Project. En este momento VS2012 nos preguntará si queremos que nos adjunte las referencias de SharePoint y que quite la página por defecto, a lo de que vamos a contestar que sí.

imageimage

Fijaos que el proyecto MVC ahora tiene las referencias de SharePoint 2013 y de Identity Framework, así como el fichero auxiliar TokenHelper.cs que nos ayudará a hacer la autenticación contra SharePoint. Además, la propiedad SSL Enabled del proyecto MVC está puesta a True porque es necesario HTTPS para que funcione el paso de credenciales.

Por último, hay que corregir la Start URL de la app (que apunta ahora a EdinSpMvc4Web/Pages/Default.aspx) editando el fichero AppManifest.xml del proyecto de app de SharePoint. Ponemos EdinSpMvc4Web/Home para apuntar al controller Home.

image

Podemos eliminar el proyecto de ASP.NET WebForms, porque ya no lo necesitamos.

Ahora vamos a agregar la “chicha”, la lógica de negocio en nuestra aplicación MVC. Para ello crearemos un controller nuevo llamado HomeController y una vista asociada llamada Index en su carpeta ViewsHome.

imageimageimageimage

En la acción Index del HomeController, vamos a ponerle el siguiente código, sin olvidarnos de poner la clausula using Microsoft.SharePoint.Client:

var contextToken = TokenHelper.GetContextTokenFromRequest(System.Web.HttpContext.Current.Request);
var hostWeb = System.Web.HttpContext.Current.Request["SPHostUrl"];

using (var clientContext = TokenHelper.GetClientContextWithContextToken(hostWeb, contextToken, Request.Url.Authority))
{
    var web = clientContext.Web;

    clientContext.Load(web, w => w.Lists.Include(l => l.Title).Where(l => !l.Hidden));
    clientContext.ExecuteQuery();
    clientContext.Dispose();

    return View(web.Lists);
}

En este ejemplo lo que hacemos es obtener el token de contexto (proporcionado por SharePoint 2013 al redireccionar a la app en Azure) y con este token de contexto abrimos un contexto de cliente (lo que necesitamos para usar el modelo de objetos de cliente de SharePoint 2013). Fijaos que no estamos proporcionando ninguna credencial de cliente, sino que la propia app se autentica contra SharePoint.

Ahora nos falta hacer que la vista muestre las listas que le hemos pasado en la acción. Abrimos la vista y le añadimos:

@{
    ViewBag.Title = "App de SharePoint con MVC";
}

<div>
    <ul>
        @foreach (var list in Model)
        {
            <li>@list.Title</li>
        }
    </ul>
</div>

Con este código conseguimos que la vista muestra las listas que le pasa el controlador. Le damos a F5 y nuestra app se ejecuta en SharePoint 2013 pero apuntando a nuestro localhost:

image

Confirmamos que nuestra app es de confianza…y vemos la app ejecutándose en MVC (en nuestra máquina):

image

Para los curiosos: el VS2012 ha agregado un ClientId y ClientSecret a nuestro web.config automáticamente (y también los ha registrado en el servidor de SharePoint). De esta manera la llamada de nuestra aplicación MVC a SharePoint está autorizada porque se basa en un ID y secreto conocidos por SharePoint.

image

El último paso que nos queda es darle un poco de aspecto de SharePoint a la app, cambiando la “master” (la vista _layout.cshtml) para incluir la barra de herramientas de SharePoint 2013.

En la sección BODY añadiremos un DIV a modo de “placeholder” donde insertaremos la barra de herramientas.

<div id="barraSharePoint"></div>

En la sección HEAD, debajo de la referencia a @Scripts.Render("~/bundles/modernizr"), agregaremos el código siguiente:

<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>
<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js"></script>     
    
<script type="text/javascript">
  var hostweburl;
  $(document).ready(function () {
      hostweburl = decodeURIComponent(getQueryStringParameter("SPHostUrl"));
      var scriptbase = hostweburl + "/_layouts/15/";
      $.getScript(scriptbase + "SP.UI.Controls.js", renderChrome)
  });
  function renderChrome() {
      var options = {
          "appIconUrl": "/Content/Images/user-logo.png",
          "appTitle": "@ViewBag.Title",
          "settingsLinks": [
              {
                  "linkUrl": "http://spblogedin.blogspot.com",
                  "displayName": "Blog de Edin"
              }
          ]
      };
      var nav = new SP.UI.Controls.Navigation("barraSharePoint", options);
      nav.setVisible(true);
  }
  function getQueryStringParameter(paramToRetrieve) {
      var params =
          document.URL.split("?")[1].split("&");
      var strParams = "";
      for (var i = 0; i < params.length; i = i + 1) {
          var singleParam = params[i].split("=");
          if (singleParam[0] == paramToRetrieve)
              return singleParam[1];
      }
  }
</script>

Lo que hace este código es obtener la URL del SharePoint (el parámetro SPHostUrl)  y llamar a su script SP.UI.Controls.js que se encarga de dibujar la UI. Lo llamamos desde SharePoint mediante una llamada a $.getScript (para evitar el problema de JS cross-domain) y en la función de callback pintamos una barra (un control SP.UI.Controls.Navigation). Para construir este control le pasamos un objeto JS con las propiedades que van a controlar la manera en la que se va a dibujar. He aprovechado también para agregar un pequeño logo para la aplicación, creando una carpeta Images dentro de Content en el proyecto MVC y subiendo el logo por defecto de una aplicación de LightSwitch.

Ahora ya estamos preparados para hacer un Deploy Solution en vez de un F5. Se nos vuelve a abrir una instancia del navegador pidiendo autorización para la app. La sorpresa es que esta vez nuestra aplicación de MVC está en el sitio web de Azure para Office Developers (dominio o365apps.net), como podéis observar:

image

Además, la aplicación ahora tiene una pinta más “SharePointera” y con un menú de control que tiene el enlace a este blog Winking smile

image

Os dejo el código fuente en mi SkyDrive, por si no tenéis ganas de escribir código, jeje.

En la próxima entrega de esta serie veremos como hacer una aplicación Provider-hosted en Azure, con lo que podemos aprovechar todos los servicios que nos ofrece Azure para construir nuestra app.

Las Apps de SharePoint 2013 (III): La primera app

Despúes de ver la introducción al modelo de las aplicaciones de SharePoint 2013 y de repasar los conceptos básicos de la infraestructura, vamos a profundizar en nuestro viaje creando una aplicación sencilla alojada en SharePoint.

La aplicación de ejemplo mostrará la ocupación en MB de un sitio de SharePoint y se actualizará mediante un botón “Refrescar”. El cálculo del espacio se hará sumando los tamaños de los ficheros alojados en las bibliotecas de ese sitio.

Crear la aplicación en Visual Studio 2012

Para empezar, abriremos Visual Studio 2012 y crearemos una nueva app de SharePoint 2013 con el nombre SpaceCounter.

New SharePoint 2013 app project

Acto seguido, completaremos los detalles del nombre (SpaceCounter) y la URL de prueba de la aplicación (http://sp2013). Es muy importante que elijamos la opción “SharePoint-hosted” en el último cuadro desplegable. Clicamos “Finish” y esperamos que Visual Studio cree la aplicación.

image

Echemos un vistazo a lo que ha generado VS2012. Veremos que hay un fichero llamado AppManifest.xml y una estructura de carpetas dentro del proyecto. El AppManifest.xml es el descriptor de la app para SharePoint: aquí está su ID (Guid), su nombre, el logo y la enumeración de recursos que necesita (permisos, tokens etc).

SharePoint app project open in VS2012

Para poder acceder al sitio host (el sitio desde el cual accedemos a la app), hay que editar el manifiesto en la parte de “Permission requests” y dar permisos de lectura al objeto Web, editando el grid que hay en ese apartado.

image

La solución está empaquetada junto con una feature (característica) de SharePoint, (auto)llamada SpaceCounter Feature1. En ella están definidas los módulos auxiliares y los ficheros que estos modulos contienen:

image

La carpeta Scripts contiene el fichero JS de la lógica de nuestra aplicación (App.js) junto con jQuery y otros ficheros JS auxiliares. Cabe recordar que no podemos usar código de servidor de SharePoint en nuestra app, aunque esté alojada en SharePoint.

La carpeta Content tiene el fichero CSS de la app y la carpeta Images las imágenes.

La carpeta Pages contienen las vistas (páginas HTML o ASPX de SharePoint, sin código de servidor). En nuestro caso tenemos la página Default.aspx que contiene un ejemplo de app que muestra el nombre del usuario.

image

Nuestro trabajo consistirá en modificar el fichero JS y el ASPX para introducir nuestra lógica y la vista HTML adecuada.

Crear la vista

Primero eliminaremos los restos de la app de ejemplo, concretamente el elemento p con el id ”message”. En su lugar pondremos el código siguiente:

La vista también tiene un pequeño script que invoca la función sharePointReady() al acabar de cargar. Allí cambiaremos el tag script para cargar el contexto del sitio host (en vez del contexto del sitio de la aplicación) y para volver a invocar la función mediante el botón Refresh. Aquí añadimos una función auxiliar llamada getParameterByName que nos sacará los parámetros de la URL de la aplicación. (Si a estas alturas tenemos dudas sobre que es el sitio host y que es el sitio de la aplicación, repasemos el post anterior donde explico estos conceptos).

<script type=”text/javascript”>
var hostweburl;
var appweburl;

$(document).ready(function () {
hostweburl = getParameterByName(“SPHostUrl”);
appweburl = getParameterByName(“SPAppWebUrl”);
var scriptbase = hostweburl + “/_layouts/15/”;
$.getScript(scriptbase + “SP.Runtime.js”,
function () {
$.getScript(scriptbase + “SP.js”,
function () { $.getScript(scriptbase + “SP.RequestExecutor.js”, sharePointReady); }
);
}
);
$(“#btnRefresh”).click(function () { sharePointReady(); });
});

function getParameterByName(name) {
name = name.replace(/[[]/, “\[“).replace(/[]]/, “\]”);
var regexS = “[\?&]” + name + “=([^&#]*)”;
var regex = new RegExp(regexS);
var results = regex.exec(window.location.search);
if (results === null)
return “”;
else
return decodeURIComponent(results[1].replace(/+/g, ” “));
}
</script>

Crear la lógica

Reemplazaremos el contenido del fichero App.js con este código en JS:

var context;
var lists;

// This function is executed after the DOM is ready and SharePoint scripts are loaded
// Place any code you want to run when Default.aspx is loaded in this function
// The code creates a context object which is needed to use the SharePoint object model
function sharePointReady() {
context = new SP.ClientContext(appweburl);
var factory = new SP.ProxyWebRequestExecutorFactory(appweburl);
context.set_webRequestExecutorFactory(factory);
var appContextSite = new SP.AppContextSite(context, hostweburl);
var web = appContextSite.get_web();
lists = web.get_lists();
context.load(lists);
context.executeQueryAsync(onGetListsSuccess, onGetListsFail);
}

function onGetListsSuccess(sender, args) {
var listsEnumerator = lists.getEnumerator();
var listItemsArray = [];
var i = 0;
var size = 0;
// — Agrupamos todas las query en un solo objeto cliente
var query = SP.CamlQuery.createAllItemsQuery();
while (listsEnumerator.moveNext()) {
var list = listsEnumerator.get_current();
// — Miramos si la lista es una biblioteca
if (list.get_baseType() === 1) {
listItemsArray[i] = list.getItems(query);
context.load(listItemsArray[i], ‘Include(File, FileSystemObjectType, File.Length)’);
i++;
}
}
// — Ejecutamos la query con todas las listas de golpe
context.executeQueryAsync(function (sender, args) {
// — Recogemos el resultado para cada una de las listas
for (j = 0; j < i; j++) {
items = listItemsArray[j];
var itemEnumerator = items.getEnumerator();
while (itemEnumerator.moveNext()) {
var item = itemEnumerator.get_current();
// — Solo nos interesan ficheros (fsoType = 0)
if (item.get_file() !== null) {
if (item.get_fileSystemObjectType() === 0) {
size = size + item.get_file().get_length();
}
}
}
}
var totalSizeInKB = size / 1024;
totalSizeInKB = totalSizeInKB.toFixed(2);
$(“#spaceInKB”).text(totalSizeInKB + ” KB”);
}, onGetListsFail);
}

function onGetListsFail(sender, args) {
alert(‘Failed to get list data. Error:’ + args.get_message());
}

La función sharePointReady() será el punto de entrada. Aquí listaremos las todas las listas de nuestro sitio de host (pasado como parámetro appWebUrl desde Default.aspx) mediante el método get_lists(). En el callback de la ejecución de esta consulta, llamaremos a la función onGetListsSucccess().

En esta función ya tenemos las listas del sitio host y haremos una consulta recursiva por cada lista. Para no hacer N llamadas a SharePoint, agruparemos todas las consultas en un array y haremos la consulta CAML de todos los elementos a SharePoint con todas las listas a la vez. Al volver de la consulta, sumaremos los tamaños en bytes de cada elemento de tipo documento.

Para evitar los errores, sólo haremos la consulta de aquellas listas que tengan como tipo base la biblioteca de documentos (list.get_baseType() === 1).

Nota: para poder acceder a la propiedad File de un elemento, donde tenemos el tamaño en bytes, hay que cargar previamente estas propiedades mediante esta linea: context.load(listItemsArray[i], ‘Include(File, FileSystemObjectType, File.Length)’);

Al final, escribiremos el tamaño de la suma (redondeado a 2 decimales) en el espacio previsto en la vista.

Desplegar y probar

Para desplegar la app, haremos una ejecución apretando F5. Visual Studio empaquetará la solución y la subirá a SharePoint, quitando antes la versión anterior, si la hubiera.

image

Al proyecto le he añadido una imagen como logo de la aplicación, de tamaño 96×96 pixeles.

Una vez desplegada la app, se nos mostrará la pantalla de confirmación de permisos para la aplicación. Aquí se nos pide acceder en modo lectura a las listas y bibliotecas del sitio host. Confirmamos la elección clicando el botón “Trust”.

image

Ahora, nuestra app sale en la lista de contenidos del sitio.

image

Clicando en nuestra app, se abre una nueva ventana con la app en ejecución.

image

Nota: si os pica la curiosidad, podéis examinar la URL que se lanza al abrir la aplicación.

http://app-6855013c35bdd3.app.sharepoint.local/SpaceCounter/Pages/Default.aspx?SPHostUrl=http%3A%2F%2Fsp2013&SPLanguage=en%2DUS&SPAppWebUrl=http%3A%2F%2Fapp%2D6855013c35bdd3%2Eapp%2Esharepoint%2Elocal%2FSpaceCounter

Aquí podemos ver la URL del sitio de la app, la URL de inicio de la app y los tres parámetros que se pasan por defecto: la URL del sitio host (SPHostWebUrl), la URL del sitio web de la app (SPAppWebUrl) y el idioma (SPLanguage).

Podéis descargar el código fuente de esta aplicación en mi cuenta de SkyDrive.

En el próximo post vamos a ver como mejorar la app y como incrustarla en el sitio host.