Un SharePoint hébergé par un fournisseur s’exécutant sur Azure cesse de fonctionner après une mise à jour .NET
Cet article est basé sur une contribution de Westley Hall, ingénieur de l’équipe SharePoint support technique pour les développeurs.
Symptômes
Vous constatez qu’un add-in cesse de fonctionner dans les conditions suivantes :
- Vous avez un SharePoint hébergé par un fournisseur qui s’exécute sur les services web Azure.
- Le add-in est hébergé sur une page SharePoint qui se trouve à l’intérieur d’un élément d’application (ou d’un élément Web Part client ou d’un add-in) ou d’un iFrame.
Cause
Le problème est probablement dû à une modification de la propriété de cookie SameSite par défaut.
Un déploiement récent .NET Framework de mise à jour réinitialise la valeur de propriété SameSite par défaut sur le cookie ASP.NET_SessionId sur Lax. Cette modification empêche l’envoi du cookie à un iFrame si le domaine de l’iframe est différent du domaine de la page hôte. Dans un SharePoint de contenu web hébergé par un fournisseur, l’iframe se fera toujours dans un autre domaine.
Par exemple, le cookie de session ressemble à ce qui suit :
Set-Cookie: ASP.NET_SessionId=<xxxxxxxx>; path=/; HttpOnly; SameSite=Lax
Notes
Dans cet exemple, <xxxxxxx> est un identificateur aléatoire de la session.
Cette session est généralement utilisée dans l’application ASP.NET pour maintenir l’authentification. La page tente de rediriger vers l’authentification à la deuxième tentative au lieu d’utiliser la session en cas de publication ou d’appel AJAX vers la même application.
Parfois, le service d’annuaire génère une erreur « 405 Method Not Allowed ». Cela est dû au fait que les appels AJAX peuvent déclencher une demande CORS OPTIONS et SharePoint refusera une telle demande.
Résolution
Pour résoudre ce problème, définissez les valeurs par défaut dans le fichierweb.config comme suit dans la section system.web :
<system.web>
<httpCookies sameSite="None" requireSSL="true"/>
<sessionState cookieSameSite="None" />
Notes
Si SameSite est définie sur Aucun, SharePoint ne force pas la condition requise pour que l’iframe et l’hôte se trouve dans le même domaine.
Pour mettre à jour leWeb.config sur l’instance en direct de votre application web Azure, suivez les étapes suivantes :
Accédez aux paramètres de votre application web dans le portail Azure.
Sélectionnez Outils avancés, puis sélectionnez Go.
Dans l’écran Kudu, sélectionnez Console de débogage, puis sélectionnez CMD.
Dans l’écran d’affichage de fichier, entrez la commande CD site\wwwroot (affichée dans la zone rouge inférieure de la capture d’écran suivante) pour obtenir le répertoire racine de l’application web. Appuyez ensuite sur Entrée.
Notes
La liste des fichiers dans la partie supérieure de la page est actualisée pour afficher le fichier Web.config (vous de devez peut-être le faire défiler pour le voir). Pour modifier le fichier, sélectionnez l’icône d’édition (le crayon, comme illustré dans la zone rouge de l’image ci-dessous).
Ajoutez les paramètres de cookie httpCookies et sessionState qui sont mis en évidence dans la capture d’écran suivante. Si la section system.web est manquante, ajoutez-la de sorte qu’elle ressemble à l’exemple illustré dans la capture d’écran suivante.
- Sélectionnez Enregistrer.
- Vérifiez que vos composants Web Parts de votre application fonctionnent comme prévu.
Pour les déploiements futurs, nous vous recommandons d’ajouter cette modification à tous les projets de code source à partir des quel l’application web a été déployée.
Plus d’informations
Pour plus d’informations sur la mise .NET Framework jour, voir Azure App Service — Gestion des cookies SameSite et .NET Framework correctif 4.7.2.
Encore besoin d’aide ? Accédez au site de la Communauté SharePoint.