Freigeben über

Fehlerbehebung bei besonders vertrauenswürdigen SharePoint-Add-Ins

  • Artikel

Verwenden des Fiddler-Tools

Das kostenlose Fiddler-Tool kann zum Erfassen der HTTP-Anforderungen verwendet werden, die von der Remotekomponente Ihres Add-Ins an SharePoint gesendet werden.

Es gibt eine kostenlose Erweiterung für dieses Tool, die automatisch die Zugriffstoken in den Anforderungen entschlüsselt.

Nachdem Sie Fiddler auf dem Webanwendungsserver installiert haben, fügen Sie das folgende Markup zur Datei web.config hinzu, damit Anforderungen von Ihrer Remoteweb-App über diesen Proxy gehen. Auf diese Weise können Sie eine Fiddler-Ablaufverfolgung erfassen und die vollständige Antwort von SharePoint anzeigen, wenn Sie eine Fehlermeldung erhalten.

Hinweis

Stellen Sie sicher, dass Sie dieses Markup entfernen, wenn Fiddler nicht ausgeführt wird. Wenn Sie das Markup nicht entfernen, kann Ihr Add-In keine HTTP-Anforderungen durchführen.

<system.net>
  <defaultProxy>
    <proxy usesystemdefault="False" bypassonlocal="False" proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>

Nachdem Sie Fiddler installiert haben, können Sie auch die Antwortheader von SharePoint überprüfen, die eine Anforderungs-GUID enthalten. Diese Anforderungs-GUID ist eine Korrelations-ID, die Sie in den Protokollen nachschlagen können, um Protokollfehler im Zusammenhang mit dieser Anforderung zu finden.

Fehler „401 - Nicht autorisiert“

Ein 401 Unauthorized-Fehler kann durch verschiedene Dinge verursacht werden, wenn das besonders vertrauenswürdige Add-In erstmals auf SharePoint zugreift. Wenn Sie das clientseitige Objektmodell (CSOM) verwenden, sieht der Fehler in etwa wie folgt aus:

[WebException: The remote server returned an error: (401) Unauthorized.]
   System.Net.HttpWebRequest.GetResponse() +8515936
   Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute() +178
   Microsoft.SharePoint.Client.ClientRequest.ExecuteQueryToServer(ChunkStringBuilder sb) +1427
   Microsoft.SharePoint.Client.ClientRequest.ExecuteQuery() +270
   Microsoft.SharePoint.Client.ClientRuntimeContext.ExecuteQuery() +146
   Microsoft.SharePoint.Client.ClientContext.ExecuteQuery() +666
   S2STestWeb.Default.Page_Load(Object sender, EventArgs e) in c:\MyFiles\HightrustTest\HightrustTestWeb\Default.aspx.cs:28
   System.Web.UI.Control.LoadRecursive() +71
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3178

Wenn die TokenHelper-Datei und Windows-Identität verwenden, sieht der Code, der die Ausnahme auslöst, in etwa wie folgt aus:

ClientContext clientContext = 
    TokenHelper.GetS2SClientContextWithWindowsIdentity(sharepointUrl, Request.LogonUserIdentity); 
clientContext.Load(clientContext.Web);
clientContext.ExecuteQuery();

Der erste Schritt für die Behebung des Problems besteht darin, mit dem Visual Studio-Debugger zu überprüfen, ob das Zugriffstoken und das ClientContext erfolgreich aufgebaut sind. Falls ja, untersuchen Sie die folgenden Möglichkeiten:

Mögliches Problem und Lösung:

  • Es wurde kein Benutzerprofil für den Benutzer erstellt, der auf die Remotewebanwendung zugreift. Erstellen Sie das Benutzerprofil.

  • Ihr Add-In verfügt nicht über die Berechtigung für die Ressource, auf die Sie zugreifen möchten. Öffnen Sie die SharePoint-Verwaltungsshell, und führen Sie das folgende Windows PowerShell-Cmdlet aus. Die Variable $web ist die SharePoint-Website, auf die Sie Zugriff erhalten möchten, und $appPrincipal ist die Add-In-ID. Weitere Informationen finden Sie unter Set-SPAppPrincipalPermission.

      Set-SPAppPrincipalPermission -Site $web -AppPrincipal $appPrincipal -Scope Site -Right FullControl

  • Ihre Webanwendung akzeptiert anonyme Anforderungen. Dies bedeutet, dass das Zugriffstoken keine echte Benutzeridentität enthält. Stellen Sie sicher, dass für das Stammverzeichnis Ihrer Remote-Webanwendung der anonyme Zugriff in IIS deaktiviert ist. Sie können dies auch überprüfen, indem Sie Ihre Remote-Webanwendung debuggen und den Wert von Request.LogonUserIdentity in der Datei default.aspx.cs (oder .vb) überprüfen, um sicherzustellen, dass es sich nicht um einen anonymen Benutzer handelt.

  • Ihr digitales Zertifikat wurde dem vertrauenswürdigen Zertifikatspeicher nicht hinzugefügt. Stellen Sie sicher, dass Sie die Verfahren unter Packen und Veröffentlichen besonders vertrauenswürdiger SharePoint-Add-Ins befolgt haben.

Die fehlende Übereinstimmung von Domänennamen in Konfigurationsdateien und Registrierungsformularen kann die Autorisierung verhindern. Die folgenden vier Werte müssen exakt gleich sein:

  • Die Add-In-Domäne, die angegeben wird, wenn die SharePoint-Add-In auf der Seite AppRegNew.aspx registriert wird

  • Die Domäne, unter der das Sicherheitszertifikat der Remotewebanwendung registriert ist

  • Der Domänenteil des Werts StartPage in der Datei „AppManifest.xml".

  • Der Domänenteil der URL aller Ereignisempfänger, die in der Datei „AppManifest.xml“ angegeben sind

Beachten Sie in Verbindung mit diesem Punkt Folgendes:

  • Wenn die Remotekomponente Ihres SharePoint-Add-In einen anderen Port als 443 verwendet, müssen Sie den Port ausdrücklich als Teil der Domäne an allen vier Stellen einschließen, beispielsweise MarketingServer:3333. (Sie müssen das HTTPS-Protokoll verwenden, für das der Standardport 443 ist.)

  • Die Domäne muss im StartPage-Wert (und in allen Ereignisempfänger-URLs) der Datei „AppManifest.xml“ hartcodiert werden, bevor das Add-In verpackt wird. Wenn Sie den Veröffentlichungs-Assistenten in Visual Studio zum Verpacken des Add-Ins verwenden, werden Sie nach der Domäne gefragt, und die Office Developer Tools für Visual Studio fügen diese in den Wert StartPage für Sie ein (anstelle des ~remoteWebUrl-Tokens, das beim Debuggen verwendet wird. Wenn Sie jedoch nicht den Veröffentlichungs-Assistenten verwenden, müssen Sie das Token manuell durch die Domäne (und das Protokoll) ersetzen. z. B. https://MarketingServer oder https://MarketingServer:3333.

Laufzeitfehler, der darauf hinweist, dass kein Zertifikat mit der Seriennummer vorhanden ist

Wenn Sie sicher sind, dass Sie die richtige Seriennummer des Zertifikats im web.config haben und das Zertifikat im Windows-Zertifikatspeicher angezeigt wird, ist möglicherweise ein ausgeblendetes zusätzliches Zeichen in der Seriennummer im web.config. Dies geschieht, wenn die Seriennummer aus der Microsoft Management Console kopiert und eingefügt wird. Löschen Sie den gesamten Seriennummernwert aus der Datei "web.config", und geben Sie ihn manuell erneut ein.

Siehe auch