Microsoft Loop : sous le capot

Warning

Les APIs expliquées dans cet article ne sont pas une documentation officielle et ne doivent en aucun cas être utilisées. Cet article est uniquement à des fins informatives et vise à donner un aperçu du fonctionnement interne des technologies Microsoft Loop.

Il est important de noter que l’utilisation d’APIs non officielles peut être risquée et peut entraîner des vulnérabilités de sécurité ou des comportements inattendus. Si vous prévoyez d’automatiser vos tâches Microsoft Loop en utilisant des APIs, il est fortement conseillé d’attendre la publication de la documentation officielle.

En tant que technologue curieux, j’aime regarder sous le capot des nouvelles technologies pour comprendre comment elles fonctionnent. Récemment, j’ai eu l’occasion d’explorer Microsoft Loop, un outil puissant qui réunit les équipes, le contenu et les tâches à travers les outils et les appareils, et qui est construit sur Microsoft Fluid.

En explorant Microsoft Loop, j’étais curieux de savoir comment les différentes APIs communiquent entre elles pour afficher les données que les utilisateurs voient à l’écran. En plongeant dans les APIs sous-jacentes, j’ai pu acquérir une compréhension plus profonde du fonctionnement de Microsoft Loop et des technologies qui l’alimentent. Dans cet article, je vais partager mes découvertes et donner un aperçu de la façon dont Microsoft Loop utilise les APIs pour gérer les données.

Authentification

Lorsque les utilisateurs s’authentifient avec Microsoft Loop, l’authentification se fait contre l’application Chapter 5 Fluid avec l’ID a187e399-0c36-4b98-8f04-1edc167a0996 et avec le scope https://clients.config.office.net/.default openid profile offline_access, ce qui fait de https://clients.config.office.net/ l’audience dans votre jeton JWT.

Pour garantir la sécurité du processus d’authentification, Microsoft Loop utilise le flux Authorization Code avec PKCE (Proof Key for Code Exchange). Il s’agit d’un processus d’authentification robuste qui aide à prévenir les attaques par injection de code.

En tant que passionné de technologie, j’étais intrigué par le processus d’authentification utilisé par Microsoft Loop et j’ai décidé d’essayer de reproduire le flux d’authentification pour voir si je pouvais en extraire un access token. Cependant, je me suis rapidement heurté à des obstacles, ce qui témoigne des solides mesures de sécurité mises en place par Microsoft.

Bien qu’il puisse être frustrant de ne pas pouvoir reproduire le flux d’authentification, c’est en réalité une bonne chose. Cela signifie que le processus d’authentification utilisé par Microsoft Loop est bien conçu en termes de sécurité, et que les utilisateurs peuvent avoir confiance que leurs données sont protégées.

APIs

Puisque la partie authentification n’a pas réussi à me fournir un access token, j’ai pris l’access token actif de ma session Microsoft Loop active. Ce n’est pas une bonne pratique, mais comme je l’ai dit, c’est uniquement à des fins informatives. Ainsi, avec cet access token, j’ai pu exécuter certains endpoints sur les workspaces.

Les endpoints Microsoft Loop fonctionnent actuellement sur le substrat Microsoft 365 qui joue un rôle crucial dans la facilitation des services opérant à travers diverses applications, notamment Exchange Online, SharePoint Online, Teams et d’autres. On pourrait dire que le Substrat sert de système d’exploitation pour Microsoft Cloud.

Obtenir vos composants Loop

GET https://substrate.office.com/recommended/api/beta/loop/deltasync?loopComponents=true

Ici, j’ai été agréablement surpris qu’il existe une API avec laquelle vous pouvez interroger tous les composants Loop. Par exemple, avec cette API, j’ai récupéré tous les workspaces ainsi que toutes les pages appartenant à un certain workspace. Ce qui est bien ici, c’est que vous récupérez également toutes les pages supprimées avec bien sûr la propriété “isDeleted” définie à true.

Créer un workspace

Créer un workspace semblait assez simple au départ. J’ai rapidement trouvé une API qui le faisait via une requête post avec un body. Mais il s’est avéré que cela n’avait pas l’effet escompté car mon workspace n’avait pas été créé.

En regardant de plus près, il s’est avéré qu’immédiatement après la création du workspace, une autre API était exécutée vers une collection de sites inaccessible. Cette API renvoyait un body long décrivant la page au format JSON. J’ai également remarqué que cela utilise un fluid session ID et un container ID. Le container ID est quelque chose qui doit correspondre au container que vous transmettez dans le JSON de votre page, tandis que le fluid session ID doit correspondre au session ID actuellement actif sur le serveur.

POST https://substrate.office.com/speedway/v1.0/workspaceGroups

Body :

{
     "displayName":"qsdq",
     "isPersonal":false,
     "enabledWorkloads": ["SharePoint"],
     "groupType":"Workspace"
}

Renommer un workspace

Pour renommer un workspace, le processus est assez simple. Une requête PATCH doit être effectuée vers une URL spécifique, avec le nouveau titre spécifié dans le body de la requête. Notamment, l’URL inclut un identifiant unique, qui se compose d’un préfixe (OID) suivi de deux GUIDs séparés, séparés par un symbole @.

PATCH https://substrate.office.com/speedway/v1.0/workspaceGroups('OID:GUID@GUID')

Supprimer un workspace

Supprimer un workspace est également assez simple, en effectuant une requête DELETE vers la même API que celle utilisée pour renommer un workspace.

DELETE https://substrate.office.com/speedway/v1.0/workspaceGroups('OID:GUID@GUID')

Conclusion

En conclusion, bien qu’il puisse être tentant d’explorer et d’expérimenter avec des APIs non officielles pour mieux comprendre les nouvelles technologies comme Microsoft Loop, il est important de faire preuve de prudence. Les APIs abordées dans cet article ne doivent pas être utilisées pour automatiser des processus, car cela peut poser des risques de sécurité et entraîner des comportements inattendus. Il est plutôt conseillé d’attendre la publication de la documentation officielle avant de tenter d’automatiser des tâches via des APIs.

Les APIs actuellement utilisées dans la préversion publique peuvent donner une indication de la direction que prendront les APIs officielles à l’avenir.

Dans l’ensemble, le fonctionnement interne de la préversion publique de Microsoft Loop est bien conçu et une réflexion a été menée sur certains aspects. Créer un workspace est assez complexe et j’espère que cela pourra se faire de manière plus simple une fois que les APIs officielles seront disponibles.