Entwickeln von Erweiterungen für öffentliche Projekte

Azure DevOps Services

Azure DevOps Services unterstützt sowohl private als auch öffentliche Projekte. Private Projekte beschränken den Zugriff auf authentifizierte Benutzer mit expliziten Berechtigungen. Öffentliche Projekte ermöglichen Benutzern, die nicht Mitglied sind, Projektdetails im Ansichtsmodus anzuzeigen.

Ein Benutzer, der nicht Mitglied ist, kann einer der folgenden sein:

Anonym: Nicht authentifiziert bei Azure DevOps Services
Öffentlich: Authentifiziert bei Azure DevOps Services, aber nicht mitglied der Organisation

Benutzer, die nicht Mitglied sind, sehen dieselben Ansichten wie authentifizierte Benutzer, aber Azure DevOps blendet nicht öffentliche Funktionen wie Einstellungen, Aktionen und Buildwarteschlangenvorgänge aus oder deaktiviert sie.

Von Bedeutung

Nur Organisationen, bei denen die "Öffentliche Projektrichtlinie zulassen" bereits aktiviert ist, können Projekte erstellen oder die Sichtbarkeit eines Projekts auf "öffentlich" ändern. Die Richtlinie ist nicht mehr für Organisationen verfügbar, die sie noch nicht verwenden. Microsoft empfiehlt die Verwendung von GitHub für alle Ihre öffentlichen Projektanforderungen.

Entscheiden Sie, ob eine Erweiterung für Benutzer, die nicht Mitglied sind, sichtbar sein soll

Als Erweiterungsentwickler können Sie alle oder einen Teil Ihrer Erweiterung für Nicht-Mitglieder-Benutzer verfügbar machen. Diese Benutzer können Ihre Erweiterung nur in öffentlichen Projekten verwenden. Wenn Sie ihre Erweiterung nicht für Nichtmitgliederbenutzer verfügbar machen möchten, benötigen Sie keine Änderungen, und die Entscheidung hat keine Auswirkungen auf Mitglieder, die Ihre Erweiterung in öffentlichen Projekten verwenden.

Verwenden Sie diese Checkliste, um zu entscheiden, ob Sie Ihre Erweiterung für Nichtmitgliedsbenutzer verfügbar machen sollten:

Ihre Erweiterung stellt Daten dar, die für Nichtmitglieder relevant sind.
Ihre Erweiterung trägt Fähigkeiten auf Projektebene bei
Ihre Erweiterung trägt zu Produktbereichen bei, auf die Nichtmitgliedsbenutzer zugreifen können
Ihre Erweiterung nutzt oder basiert nicht auf Funktionen, auf die Nichtmitgliedsbenutzer keinen Zugriff haben, wie beispielsweise den Erweiterungsdatendienst oder bestimmte REST-APIs von Azure DevOps Services. Weitere Informationen finden Sie im Abschnitt "Einschränkungen" .

Konfigurieren der Sichtbarkeit von Beiträgen

Standardmäßig zeigt Azure DevOps nur Beiträge für Organisationsmitglieder an. Legen Sie das restrictedTo Attribut für diesen Beitrag fest, um Nichtmitgliedsbenutzern eine Sichtbarkeit zu verleihen. Der Wert ist ein Zeichenfolgenarray, das auflistet, welche Benutzertypen den Beitrag sehen sollen. Zu den möglichen Werten gehören:

member: Ein authentifizierter Benutzer, der Mitglied der Organisation ist
public: Ein authentifizierter Benutzer, der kein Mitglied der Organisation ist
anonymous: Ein nicht authentifizierter Benutzer

Einen Hub für anonyme, öffentliche und Mitglieder sichtbar machen

{
    "contributions": [
        {
            "id": "my-hub",
            "type": "ms.vss-web.hub",
            "targets": [
                "ms.vss-code-web.code-hub-group"
            ],
            "restrictedTo": [
                "member",
                "public",
                "anonymous"
            ],
            "properties": {
                ...            
            }
        }
    ]
}

Sie können auch die Standardsichtbarkeit für alle Beiträge in Ihrer Erweiterung festlegen, indem Sie das restrictedTo Attribut im Stammverzeichnis Ihres Erweiterungsmanifests festlegen. Sie können diese Standardeinstellung dann für einzelne Beiträge außer Kraft setzen.

Machen Sie alle Beiträge, mit Ausnahme von einem, für alle Benutzer sichtbar

{
    "id:": "my-extension",
    "name": "My Extension",
    "version": "1.0.0",
    ...
    "restrictedTo": [
           "anonymous",
           "public",
           "member"
    ],
    "contributions": [
        {
            "id": "my-member-only-widget",
            "type": "ms.vss-dashboards-web.widget",
            "restrictedTo": [
                "member"
            ],
            "properties": {
                ...
            }
        },
        {
            "id": "my-hub",
            "type": "ms.vss-web.hub",
            "targets": [
                "ms.vss-code-web.code-hub-group"
            ],
            "properties": {  
                ...              
            }
        },
        {
            "id": "my-second-hub",
            "type": "ms.vss-web.hub",
            "targets": [
                "ms.vss-work-web.work-hub-group"
            ],
            "properties": {  
                ...              
            }
        }            
    ]
}

Verständnis von Einschränkungen für Nicht-Mitglied-Nutzer

Wenn Sie einige oder alle Aspekte Ihres Beitrags für öffentliche Benutzer zur Verfügung stellen möchten, sollten Sie die folgenden Einschränkungen berücksichtigen.

VSS SDK-Methodeneinschränkungen

Das kerne SDK-Skript, VSS.SDK.js, ermöglicht es Weberweiterungen, mit dem übergeordneten Frame zu kommunizieren, um Vorgänge wie initialisieren der Kommunikation und Abrufen aktueller Benutzerkontextinformationen auszuführen. Die folgenden VSS SDK-Methoden unterstützen keine Benutzer, die nicht Mitglied sind:

VSS.getAccessToken()
VSS.getAppToken()

Einschränkungen des Erweiterungsdatendiensts

Da der Erweiterungsdatendienst Daten verwaltet, die nicht auf ein Projekt festgelegt oder gesichert sind, können Nichtmitglieder keine Erweiterungsdaten lesen oder schreiben.

Behandeln von Datenzugriffsfehlern

Wenn der Datendienst aufgrund von Berechtigungseinschränkungen durch den aufrufenden Benutzer nicht auf Daten zugreifen kann, wird die vom Aufruf getValue zurückgegebene Zusage abgelehnt. Der an die Reject-Funktion übergebene Fehler verfügt über eine Namenseigenschaft, die Ihnen hilft, zu verstehen, warum der Aufruf keine Daten lesen oder schreiben konnte.

VSS.getService(VSS.ServiceIds.ExtensionData).then(function(dataService) {
    dataService.getValue("someKey").then(function(value) {
         // Process the value
    }, function(error) {
       if (error.name === "AccessCheckException") {
           alert(error.message);
       }
    });
});

REST-API-Zugriff

Azure DevOps Services bietet einen begrenzten Satz von REST-APIs für Benutzer, die nicht Mitglied sind. Diese APIs umfassen die meisten APIs auf Organisationsebene und Projektebene für Features, auf die Nichtmitgliederbenutzer allgemein zugreifen können. Berücksichtigen Sie diese Informationen, wenn Sie entscheiden, ob Sie Ihre Erweiterung für Nicht-Mitglieder-Benutzer verfügbar machen möchten.

Es wird empfohlen, version 5.0 und höhere APIs zu verwenden, da Azure DevOps bestimmte APIs nur ab Version 5.0 für Nichtmitgliedsbenutzer zur Verfügung stellt.

Identitätsreferenzen

Die meisten Rest-APIs von Azure DevOps Services verwenden einen allgemeinen "Vertrag", um einen Benutzer oder eine Gruppe darzustellen. Um Mitgliedsinformationen wie E-Mail-Adressen zu schützen, lässt Azure DevOps bestimmte Felder, wie uniqueName, aus, wenn es von einem anonymen oder öffentlichen Benutzer eine REST-API aufgerufen wird.

Überprüfen Sie die Benutzerberechtigungen.

Verwenden Sie Berechtigungen, um zu entscheiden, ob eine Funktion in Ihrer Erweiterung angezeigt oder aktiviert werden soll. Verwenden Sie die Sicherheits-REST-API aus Weberweiterungscode, um zu überprüfen, ob der aktuelle Benutzer über die Berechtigung in Azure DevOps Services verfügt, um die Aufgabe abzuschließen. Dieser Ansatz verhindert, dass Benutzer denken, dass sie berechtigt sind, etwas zu tun, nur um zu ermitteln, dass sie nicht.

Überprüfen, ob der Benutzer die Berechtigung hat, Builds in die Warteschlange zu stellen.

In diesem Beispiel wird gezeigt, wie Sie mithilfe des Security REST-Clients überprüfen können, ob der Benutzer über die Berechtigungen verfügt, um Builds in die Warteschlange zu stellen im aktuellen Projekt. Standardmäßig besitzen Benutzer, die nicht Mitglied sind, diese Berechtigung nicht.

VSS.require(["VSS/Service", "VSS/security/RestClient"], function(VSS_Service, Security_RestClient) {
   var client = VSS_Service.getCollectionClient(Security_RestClient.SecurityHttpClient3);
 
   var securityToken = VSS.getWebContext().project.id;
 
   client.hasPermissionsBatch({
    evaluations: [
       {
           "securityNamespaceId": "33344D9C-FC72-4d6f-ABA5-FA317101A7E9",
           "token": securityToken,
           "permissions": 128 /* queue builds */
       }
    ],
    alwaysAllowAdministrators: true
}
).then(function(response) {
     console.log("Can user queue builds in this project? " + response.evaluations[0].value);
  });
});

Genau wie andere Arten von Beiträgen steuert die restrictedTo Beitragseigenschaft die Sichtbarkeit von Dashboard-Widget-Beiträgen. Um z. B. ein Widget für Nichtmitglieder- und Mitgliedsbenutzer sichtbar zu machen:

{
  "contributions": [
    {
      "id": "HelloWorldWidget",
      "type": "ms.vss-dashboards-web.widget",
      "targets": [
        "ms.vss-dashboards-web.widget-catalog"
      ],
      "restrictedTo": [
        "member",
        "public",
        "anonymous"
      ],
      "properties": {
          ...
      }
    }
  ]
}

Wenn Sie die Sichtbarkeit des Widgets für Nichtmitglieder steuern, bietet das Dashboard-Framework auch einen optionalen offenen Formularspeichermechanismus für Widgeteinstellungen. Zwei Mechanismen geben an, ob Widgeteinstellungen für Nichtmitgliedsbenutzer in öffentlichen Projekten verfügbar sind.

Ein Widget mit konfigurierbaren Einstellungen, die für Nichtmitglieder-Benutzer sichtbar sind, müssen einem der folgenden Muster folgen. Wenn Sie diese Muster nicht befolgen, wird verhindert, dass das Widget für diese Benutzer angezeigt wird.

Legen Sie die canStoreCrossProjectSettings-Eigenschaft des Widgets auf false fest, was angibt, dass die Widgeteinstellungen projektspezifisch sind.

{
    "id:": "HelloWorldWidget",
    "type": "ms.vss-dashboards-web.widget",
    ...
    "properties": {
        "canStoreCrossProjectSettings": false
    }
}

Einzelne Widgetinstanzen können auch angeben, dass ihre Einstellungen projektspezifisch und für Nichtmitgliedsbenutzer verfügbar sind. Beim Speichern der Einstellungen sollte das Widget hasCrossProjectSettings zu false in der JSON-Zeichenfolge setzen.

{
    "hasCrossProjectSettings": false,
    "hypotheticalWidgetOption": true,
    "backlogLevel": "Stories"
}

Berücksichtigen Sie die Build- und Releaseanforderungen

Wenn Ihre Erweiterung einen Build- oder Freigabevorgang beiträgt, benötigen Sie keine Änderungen, um diesen Vorgang aus einer Pipeline in einem öffentlichen Projekt zu verwenden.

Behandeln von Überlegungen zur Nachverfolgung von Arbeitsaufgaben

Erweiterungen funktionieren für Nicht-Mitglieder im Kontext eines öffentlichen Projekts nicht ohne Anpassungen. Dazu gehören das Arbeitsaufgabenformular, andere Arbeitsaufgabenoberflächen und die Interaktion mit REST-APIs für Arbeitsaufgaben.

Einschränkungen des Arbeitselementformulars

Azure DevOps verhindert alle Aktualisierungen oder Löschungen von Arbeitsaufgaben für Benutzer, die nicht Mitglied sind.

Identitätsverarbeitung

In Azure DevOps Services REST API Version 5.0 und höher gibt der Dienst Identitäten als IdentityRef Objekte anstelle von Zeichenfolgen zurück. Wie zuvor beschrieben, gibt Azure DevOps bestimmte Felder wie uniqueName in diesen Objekten nicht zurück, wenn ein Benutzer, der kein Mitglied ist, den API-Aufruf durchführt.

API-Bereichseinschränkungen

Erweiterungen können nur projektbezogene REST-APIs aufrufen, wenn der aktuelle Benutzer kein Organisationsmitglied ist. Azure DevOps lehnt alle REST-API-Aufrufe ab, die nicht einem Projekt zugeordnet sind.

Abfrageeinschränkungen

Benutzer, die nicht Mitglied sind, haben die folgenden Einschränkungen im Zusammenhang mit Arbeitsaufgabenabfragen:

Benutzer, die nicht Mitglied sind, können bekannte Abfragen nur anhand der ID oder des Pfads ausführen.
Abfragen müssen auf das aktuelle Projekt eingeschränkt werden. Azure DevOps schließt alle Arbeitsaufgaben aus, die nicht zum aktuellen Projekt gehören
Benutzer, die nicht Mitglied sind, können keine neuen Abfragen erstellen oder WIQL-Abfragen ausführen

Feedback

War diese Seite hilfreich?

Last updated on 2025-11-11