Article d’origine publié le mardi 28 juin 2011

J’ai récemment été témoin d’un problème qui s’est avéré assez difficile à traquer ; j’ai donc pensé à partager celui-ci et sa résolution. Dans ce cas, un fournisseur de revendications personnalisées avait été développé et était utilisé comme fournisseur par défaut pour SPTrustedIdentityTokenIssuer, comme décrit ici : http://blogs.technet.com/b/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-provider-in-sharepoint-2010.aspx. Cela semble fonctionner dans certains cas - vous pouvez effectuer une recherche, il vous affiche la liste des correspondances, vous en sélectionnez une puis cliquez sur le bouton OK. Dans certains cas, tout fonctionne correctement - la boîte de dialogue disparaît et vous voyez le nom résolu dans le contrôle de saisie. De plus, vous pouvez aussi définir un point d’arrêt dans la méthode FillResolve pour y faire un saut.

Mais dans certains cas, vous observez le comportement suivant :

  • La boîte de dialogue du sélecteur de personnes se ferme.
  • Le contrôle de saisie reste vide - rien (résolu ou autre) ne s’affiche.
  • Si vous définissez un point d’arrêt dans FillResolve, il n’est jamais atteint.
  • Si vous consultez les journaux ULS, vous ne trouvez aucune erreur.

Dans ce cas, j’ai finalement diagnostiqué ce qui se passait : le fournisseur de revendications personnalisées ajoutait un type de revendication n’ayant pas de mappage correspondant dans SPTrustedIdentityTokenIssuer. Donc par exemple, il créait une revendication dont le type était http://schemas.steve.com/foo, mais la liste des mappages de revendications pour SPTrustedIdentityTokenIssuer ne contenait aucun mappage pour http://schemas.steve.com/foo (pour un exemple sur les mappages de revendications et leur création, voir http://blogs.technet.com/b/speschka/archive/2010/02/17/creating-both-an-identity-and-role-claim-for-a-sharepoint-2010-claims-auth-application.aspx). Plutôt que d’ajouter une revendication que SharePoint connaît comme non mappée, celle-ci disparaît dans le pipeline en vous laissant un écran vide sans message d’erreur. Voilà pourquoi, ce problème peut être très long à traquer.

Pour ce problème particulier, nous avons arrêté de triturer SPTrustedIdentityTokenIssuer et de le recréer, et avons ajouté un nouveau mappage pour le type de revendication qui disparaissait du sélecteur de personnes. Nous avons à nouveau exécuté le code et cela a tout simplement fonctionné, ce qui a confirmé le problème et validé la résolution.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible ici : Name Disappears After Selecting in People Picker with Custom Claims Provider in SharePoint 2010