Le Post Infeeny

Les articles des consultants et experts Infeeny

#SPC2012 : Deliver SharePoint Apps On Non-Microsoft platforms – Lessons learned from the Trenches

Thurday, 9h00, Kirk Evans, Principal PFE, @kaevans, Dallas Texas Radu Grama, PFE, @radugrama

Résumé

Session particulière sur le développement sur des plateformes non Microsoft, pour attaquer du SharePoint. Ce scénario peut arriver dans des entreprises où les technologies sont hétérogènes, et où il peut y avoir des parties où la technologie veut se connecter à SharePoint via des Apps.

Il explique alors les problématiques de packaging, de connexion et de sécurité, et enfin de méthode d’accès aux données.

Le but de cette session est de créer des Apps grâce à des environnements non Microsoft en comprenant la sécurité. Le code va être fait en PHP dans cette session.

On nous met dans l’ambiance, c’est un Mac qui est sur scène

// Scenario Overview

Utilisation de FBA, pas de technos Microsoft.

Linux (Ubuntu 12.0.4) et AWS (Amazon Web Services), Apache, MySQL (avec un PhpMyAdmin), PHP

// DEMO :

On est sur un site PHP avec des customers et des agents dans une agence de voyage.

Un customer doit pouvoir laisser un message à un agent.

L’agent a un BO, avec un listing des hôtels et des chambres, les messages des clients, rechercher dans le listing des hôtels.

Ils gèrent les rendez-vous et opérations dans SharePoint 2013.

Le but sera de connecter les deux sites.

// Gathering requirements

Les deux systèmes vont communiquer en REST/OData Il explique ce qui se cache derrière ses environnements (Apache, mysql etc)

// App Decisions

Il revient sur les méthodes d’hébergement et explique qu’aujourd’hui, nous allons clairement être en Provider-hosted App avec un AppManifest Il revient également sur les App Experiences (Full Page Apps -obligatoire-, App Parts -optionnel-, Custom Action – optionnel-) Utilisation de O365, il va utiliser ACS (access control service), listings sont en MySQL mais les RDV seront dans SharePoint 2013.

// Packaging

Il explique que le .APP d’une App est un .ZIP.

// DEMO : Grama montre la création d’un package APP avec MonoDevelop

L’important est le AppManifest, qu’il a récupéré.

Il insiste sur la start page qu’il renvoie vers la page login de son site PHP.

Il a RemoteWebApplication dans AppPrincipal avec un ClientId qui va gérer l’authentification Il une classe console qui va lui recréer la structure d’un .APP et qui va le zipper dans un fichier .APP avec les Helpers de gestion de ZIP.

Il va sur son developer site, upload son .app.

Il explique qu’il a utilisé MonoDevelop sur Mac pour coder en .NET avec Mono.

// Retour sur les slides : Authentification et OAuth

Pour une Cloud app, il faut enregistrer l’App avec ACS (Access control services).

Utiliser les IDE pour développer l’App.

Confugrer OAuth sur l’application.

Puis package l’App.

Pour OAuth, on utilise des tokens. Il explique qu’une App agit comme une Il y a un App ID (client ID) et App Secret générés par ACS (page _layouts/15/appregnew.aspx).

https://sellerdashboard.microsoft.com/Application/Summary

Il faut utiliser cette interface pour enregistrer l’App pour qu’elle soit utilisable sur O365.

Il faut s’assurer que le formulaire d’inscription à la plateforme il faut créer un profil complet sous peine d’être refusé.

Quand il va sur l’onglet « Client Ids », il peut ajouter un client Id OAuth. Pour cela il faut qu’il mette un nom, un nom de domaine. Il récupère un Client ID et un Client Secret.

Quand il revient sur l’AppManifest c’est celui là qu’il et dans son ClientId de AppPrincipal>RemoteWebapplication // Evans explique le flux OAuth (cf session précédente qui l’évoque déjà).

Client requête SP, SP demande un context token à ACS, ACS lui renvoie un context token signé à SP, SP renvoie la page avec un iframe au client, le client demande le contenu de l’iframe à contoso.com (l’app domain), Contoso.com demande la validation du token à ACS, ACS renvoie un access token à l’App, l’App envoie la request et access token à SP, SP valide cela et renvoie les données à l’App.

Il explique que côté serveur, il y a une classe TokenHelper sauf qu’il ne peut pas l’utiliser car il est en Mono.

// DEMO : Grama explique l’équivalent TokenHelper

Il explique qu’on peut se baser sur un framework existant si on en connait, qui fonctionne avec OAuth 2.0 PHPStorm est utilisé (Eclipse serait un équivalent), et la librairie JSON Web Token (JWT) pour lui servir de TokenHelper.

  1. Il récupère la variable $_REQUEST[‘SPAppToken], et le décode grâce au CLIENT_SECRET récupéré et mis dans un fichier de variables. CLIENT SECRET fonctionne comme une clé privée. En décodant avec JWT, il obtient l’App Token.
  2. L’App Token est vide –> refuser l’accès –> Access denied.
  3. App Token est OK –> il doit maintenant récupérer l’Access Token
  4. $appToken->aud –> il split les @ et $appToken->appctxsender pour récup leprincipal name
  5. il va créer un tableau avec les paramètres de données à envoyer pour récupérer son access token (voir la documentation OAuth).
  6. Il récupère le endpoint qu’il doit requêter via AppToken->appctx->.. il passe rapidement sur le code pour récupérer l’access token
  7. Une fois qu’il a accessToken, c’est bon il a accès à SharePoint et peut attaquer les données.

L’access token dure quelques heures. Une fois qu’il est connecté il explique qu’il peut récupérer le refresh token qui lui dure de 6 à 12 mois .Ainsi il veut éviter de refaire la requête à chaque rafraichissement de la page.

// CSOM and REST / OData

Répétition de CSOM et REST via client.svc dans vti_bin … ou _api plus simplement.

Il insiste sur le fait qu’il ne va rien installer sur SP de particulier, mais bien attaquer à distance les données.

Il explique comment est venu OData, qui avant était conçu pour lire les informations, mais qui maintenant permet également de faire du CRUD. Il est aussi possible de récupérer les données en JSON avec les accepts-header HTTP.

Il créé un tableau d’en-têtes, pour envoyer sa requête GET.

Il met Authorization : Bearer en passant l’AccessToken.

Il met Accept : application/json;odata=verbose.

Il émet ensuite la requête JSON en attaquer _api/web/CurrentUser Il fait un curl_exec($ch) , $ch étant le tableau de requête, et met le résultat dans une variable session « sharepointUser ».

Christian

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :