App-Entwicklung unter SharePoint: Anonymer Zugriff

Mit SharePoint gibt es keine öffentlichen Web-Seiten für ein anonymes Publikum. Wirklich?

Es ist schon richtig: Bei SharePoint geht es um die Zusammenarbeit von Teams im Netz. Bis in die kleinsten Verästelungen der Seiten-, Daten- und Anwendungsstruktur läßt sich komfortabel bestimmen, wer was bis zu welchen Grade ausführen, sehen oder ändern darf. Hier liegt eine der großen Stärken von SharePoint.
Aber wenn wir in speziellen Einzelfällen auf diese Stärken gerade einmal gar keinen Wert legen? Was, wenn wir eine Seite einem Publikum präsentieren wollen, das wir weder kennen noch zu kennen brauchen?
Das geht mit SharePoint nicht. Oder doch?
Das geht mit SharePoint nicht. Oder doch?
Beispiel: Während der Vorproduktion zu einem Werbefilm lädt die Casting-Direktorin Aspiranten für die zu besetzenden Rollen in ihr Studio ein. Film- und Fotoaufnahmen werden gemacht, Details zu den Bewerbern werden aufgenommen, und all diese Inhalte werden, komfortabel und benutzerfreundlich aufbereitet, auf einer SharePoint-Team-Site dem inneren Kreis der an dieser Talentsuche Beteiligten bereitgestellt.
Wir sind nun dieser „innere Kreis“, haben vielleicht einige Korrekturen vorgenommen und eine Vorauswahl unter den Aspiranten getroffen, und wollen nun unsere Seite einem größeren Publikum vorstellen: dem auftraggebenden Kunden, der Werbeagentur, oder wem auch immer. Dieses größere Publikum ist weder Teil unseres SharePoint-Teams, noch wäre es praktikabel, es dazu zu machen. Wir haben es also mit einem teilweise anonymen Publikum zu tun.
Lassen Sie uns für dieses Anwendungsbeispiel weiterhin annehmen, daß wir mit der aktuellen Online-Version von SharePoint arbeiten und unsere Erweiterungen konsequenterweise als SharePoint Framework (SPFx) WebParts, also als moderne client-seitige Web-Apps mit JavaScript-Werkzeugen und -Bibliotheken, realisieren. Mit dieser zusätzlichen Bedingung fallen bei unserem Beispiel dann auch sämtliche Lösungsansätze aus, die eine benutzerdefinierte server-seitige Instanz zur Zugriffskontrolle benötigen würden.
Die gute Nachricht ist nun, daß wir eine solche benutzerdefinierte Instanz gar nicht brauchen. Entgegen der landläufigen Meinung gibt es anonyme Zugriffe auf SharePoint-Ressourcen wie Dateien, Ordner und Seiten.
So geht’s:
Wenn SharePoint Online in der Ressourcen-Anforderung keinen rtFA- oder FedAuth-Cookie findet, wird es normalerweise das Azure Active Directory bitten, den Benutzer zu authentifizieren. Für unser Szenario mit einem teilweise anonymen Publikum brauchen wir also eine Technik, um diese Anfragen zu vermeiden.
Hierzu gibt es die Spezial-Seite guestaccess.aspx, die auch dann keine Anfrage an das Azure Active Directory sendet, wenn rtFA- oder FedAuth-Cookie fehlen. Statt dessen erwartet guestaccess.aspx einen speziellen Parameter „share“. Der Wert dieses Parameters ist ein Schlüssel für eine interne Tabelle, die solche Schlüssel auf die eigentlichen Ressourcen-Adressen abbildet. Eine gültige Anfrage an guestaccess.aspx beantwortet SharePoint mit einem Redirect auf die jeweils zugeordnete Ressource und einem FedAuth Antwortcookie.
Sendet nun der Client-Browser seine Anfrage – zusammen mit dem FedAuth-Cookie – an die Redirect-Adresse, liefert SharePoint die Ressource aus: Der Benutzer ist zwar weiterhin anonym, aber der vorhandene und für die Ressource gültige FedAuth-Cookie verhindert die sonst zwingende Anfrage an das Azure Active Directory.
Zurück zu unserem Beispiel mit der Casting-Direktorin: Das SPFx WebPart, mit dem unser Team arbeitet, hat seine Datenbasis in SharePoint Listen und Content-Typen. Die mächtige Rechteverwaltung von SharePoint stellt auf komfortable Weise sicher, daß die Anfragen, die ein Benutzer vom WebPart an die Datenbasis absetzt, so beantwortet werden, wie es den Zugriffsrechten des jeweiligen Benutzers entspricht.
Eine SharePoint Liste ist nun aber keine Ressource, für die ein „share“-Schlüssel für anonymen Zugriff, so wie für Seiten, Dateien und Ordner, erstellt werden könnte. Genauer betrachtet würde unsere Casting-Direktorin und das innere Produktionsteam dem anonymen Publikum auch gar keinen ungefilterten und ungeordneten Zugriff auf die ganze Liste geben wollen. Was unser Team nach seiner Vorauswahl und Rollenzuordnung der Aspiranten im Grunde will, ist folgendes: Eine geordnete, selektierte Liste in präsentabler Form an den auftraggebenden Kunden und die Werbeagentur übergeben.
Richtig betrachtet haben wir es in unserem Anwendungsbeispiel also gar nicht mit der Anforderung zu tun, einen anonymen Zugriff auf die eigentliche Datenbasis bereitzustellen. Was wir brauchen ist der anonyme Zugriff auf das Ergebnis einer Abfrage.
Das letzte Teil des Puzzles:
Für SPFx WebParts lassen sich im Manifest beliebige Schlüssel definieren, die im Kontext einer Seite mit Werten belegt werden können. Für das aktive WebPart sind diese Schlüssel “own properties”, also direkt verfügbare Variable.
Diese preconfiguredEntries.properties sind der letzte Baustein, den wir für unsere SharePoint-Präsentation für ein anonymes Publikum brauchen: Sie enthalten das Ergebnis einer vorher durch einen authentifizierten Nutzer ausgeführten Anfrage an die Datenbasis. Die veröffentlichte dynamische Seite trägt ihre Datenbasis sozusagen mit sich herum, womit diese Datenbasis denselben Zugriffsbedingungen unterliegt, wie die Seite selbst.
Und jetzt alles zusammen:
In unserem SPFx WebPart unterscheiden wir zwischen authentifizierten Benutzern mit Zugang zu allen Funktionen und normalem Datenbankzugriff einerseits und anonymen Gästen mit eingeschränktem Zugang und ohne Datenbankzugriff andererseits.
Authentifizierte Benutzer und anonyme Gäste
Statt eine Anfrage an die Datenbank abzusetzen, wird für anonyme Gäste der Inhalt vordefinierter WebPart Properties ausgelesen.
Anonyme Gäste erhalten den Inhalt vordefinierter WebPart Properties
Für authentifizierte Benutzer stellen wir eine Funktion bereit, die programmgesteuert neue Seiten erstellt, die unseren SPFx WebPart enthalten und diesem die gewünschten Werte für die vordefinierten WebPart Properties mitgibt. Diese Werte sind beispielsweise Antworten auf CAML-Abfragen.
Authentifizierte Benutzer erhalten eine Funktion bereit, die programmgesteuert neue Seiten erstellt
Für authentifizierte Benutzer stellen wir außerdem eine Funktion bereit, die einen Eintrag für die neu erstellte Seite in die interne /ShareLink Tabelle schreibt, und einen “share”-Token für guestaccess.aspx zurückgibt. Hinweis: Die URLs, die File.getShareLink im Beispiel unten zurückgibt, machen den “share”-Token nicht direkt sichtbar, da SharePoint einen internen Kurz-URL-Dienst anwendet.
Guest-Access-Seite und Share-Token
Die von File.getShareLink zurückgegebene URL wird dann an unser „anonymes“ Publikum – beispielsweise den auftraggebenden Kunden oder die Werbeagentur – weitergegeben. Die sonst bei SharePoint übliche Aufforderung zum Sign In wird dieses Publikum nicht sehen.
0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.