Einstellungen zur Richtlinie zur Ressourcenoffenlegung einrichten
Wenn Sie ein neues Projekt starten, wird automatisch eine app.json-Datei generiert, die die Informationen zu der Erweiterung enthält, auf der Sie aufbauen.
In der Datei app.json können Sie eine Einstellung namens resourceExposurePolicy angeben, die die Zugänglichkeit der Ressourcen und des Quellcodes während verschiedener Operationen definiert.
Die resourceExposurePolicy gibt die folgende Liste von Optionen an:
applyToDevExtension
allowDebugging
allowDownloadingSource
includeSourceInSymbolFile
Jede dieser Eigenschaften legt die spezifischen Bereiche fest, in denen auf den Quellcode einer Erweiterung zugegriffen werden kann. Alle Optionen sind standardmäßig auf „false“ gesetzt. Dies bedeutet, dass standardmäßig keine abhängige Erweiterung den Quellcode Ihrer Erweiterung debuggen oder herunterladen kann.
Die Syntax der Einstellung resourceExposurePolicy lautet folgendermaßen:
`"resourceExposurePolicy": {"applyToDevExtension": <boolean>, "allowDebugging": <boolean>, "allowDownloadingSource": <boolean>, "includeSourceInSymbolFile": <boolean>}`
In der Projektvorlage AL:Go! sind jetzt standardmäßig „allowDebugging“, „allowDownloadingSource“ und „includeSourceInSymbolFile“ aktiviert. Dies wird in der Datei app.json angezeigt, wo die Eigenschaft resourceExposurePolicy des Projekts eingerichtet ist.
Sie können dies jederzeit für Ihre AppSource oder Mandantenerweiterung überschreiben, indem Sie die Einstellung ändern.
Die Vorlage AL: Go! richtet die Optionen allowDebugging, allowDownloadingSource und includeSourceInSymbolFile in der resourceExposurePolicy auf true ein.
applyToDevExtension
Mit dem Kennzeichen applyToDevExtension können Sie angeben, ob alle für die Erweiterung angegebenen Richtlinien zur Ressourcenverfügbarkeit auch für Entwicklererweiterungen gültig sind, indem Sie den Wert auf „true“ setzen.
allowDebugging
Richten Sie das Kennzeichen allowDebugging ein, um das Debuggen in Ihrer Erweiterung zuzulassen, wenn die Erweiterung als Abhängigkeit verwendet wird. Andernfalls ist das Debuggen nicht erlaubt. Der Standardwert von allowDebugging ist false.
Wenn Sie Debuggern in Ihrer Erweiterung erlauben möchten, den Quellcode anzuzeigen, muss die Eigenschaft allowDebugging in der Datei app.json auf true festgelegt werden. Wenn zum Beispiel jemand eine Erweiterung A entwickelt und er oder jemand anderes im Team Erweiterung B entwickelt und B von A abhängt, wird das Debuggen von B nur dann in den Code für A eintreten, wenn eine Methode von A aufgerufen wird und wenn das Kennzeichen allowDebugging in der App.json-Datei für die Erweiterung A auf true eingestellt ist, wie im Beispiel unten gezeigt. Durch Hinzufügen dieser Einstellung aktivieren Sie das Debuggen in einer Erweiterung, um den Quellcode und die Variablen anzuzeigen, wenn diese Erweiterung als Abhängigkeit eingerichtet ist.
"resourceExposurePolicy": {"allowDebugging": true}
allowDebugging ist nicht nur gültig für Profile, Seitenanpassungen und Ansichten, weil diese Objekte keine benutzerdefinierte Logik in Prozeduren oder Triggern definieren kann. Der Code für Profile, Seitenanpassungen und Ansichten definiert in einer Erweiterung mit allowDebugging auf false gesetzt, und darauf kann noch immer mit dem Designer zugegriffen werden, und es kann mit diesem kopiert werden.
Das [NonDebuggable]-Attribut
Das Einrichten von allowDebugging auf true erlaubt es, in diesen Code einzusteigen, es sei denn, Sie haben das Attribut [NonDebuggable] für Methoden und Variablen angegeben. Wenn Sie jedoch die mit [NonDebuggable] gekennzeichneten Methoden und Variablen markiert haben, bleiben diese Methoden und Variablen nicht debug-fähig.
Der Standardwert des Kennzeichens allowDebugging ist false. Wenn allowDebugging auf true gesetzt ist, kann jeder, der Ihren Code erweitert, ihn zu debuggen.
Es ist jedoch nicht möglich, sowohl Debuggen als auch Zur Definition wechseln zuzulassen und dennoch die Quelle vor dem Extrahieren durch die Debugerfahrung zu schützen, beispielsweise durch die Verwendung von Visual Studio Code-Tools-Drittanbietern. Für AppSource-Apps wird empfohlen, den Zugriff auf die Quelle einzuschränken, indem Sie die resourceExposurePolicy-Kennzeichen auf „false“ setzen, wenn Sie Ihre IP-Adresse schützen möchten. Verlassen Sie sich dann auf die Möglichkeit, sich selbst und optional vertrauenswürdigen Partnern im Wiederverkauf zeitlich begrenzten individuellen Zugriff durch die dynamische Überschreibung der Ressourcenrichtlinie zu gewähren.
Wenn der Kunde die IP besitzt und der Offenlegung zustimmt, wird für mandantenabhängige Erweiterungen empfohlen, zumindest das Debuggen zuzulassen und die Quelle in Symbole einzuschließen, um die Fehlerbehebung, das Extrahieren der IP aus dem Dienst und die Arbeit zwischen Wiederverkäufern zu vereinfachen.
Jemand kann Ihren Code weiterhin anzeigen, wenn eine Erweiterung über Visual Studio Code als DEV-Erweiterung bereitgestellt wird, im Gegensatz zur Bereitstellung mithilfe eines Cmdlets, mithilfe der Seite Erweiterungsverwaltung in Business Central oder mithilfe von AppSource. Verwenden Sie die Einstellung applyToDevExtension, um festzulegen, ob alle Richtlinien zur Ressourcenverfügbarkeit auch für Ihre DEV-Erweiterung gelten sollen.
allowDownloadingSource
Wenn dieses Kennzeichen in der app.json-Datei der Erweiterung A auf true gesetzt ist, können die Quellknoten und Mediendateien der Erweiterung A heruntergeladen werden, zum Beispiel von der Option Download-Quelle auf der Seite „Erweiterungsverwaltung“ in Business Central. Erweiterung A kann eine PTE‑ oder eine DEV-Erweiterung sein. Der Standardwert von allowDownloadingSource ist false.
includeSourceInSymbolFile
Wenn dieses Kennzeichen in der Datei app.json der Erweiterung A auf „true“ gesetzt ist, enthält die heruntergeladene Symboldatei in Visual Studio Code, auf den über die Funktion Symbole herunterladen zugegriffen wird, Symbole, Quellcode und alle anderen Ressourcen der Erweiterung A umfasst. Wenn includeSourceInSymbolFile auf false eingerichtet ist, steht die Quelle nicht in den Symboldateien zur Verfügung, und Sie können nicht Zur Definition wechseln verwenden, um die Quelle anzuzeigen. Sie können die Funktion in Erweiterung A jedoch weiterhin erweitern, IntelliSense abrufen und aufrufen, indem Sie sich auf die exponierten Symbole und Signaturen verlassen. Der Standardwert des Kennzeichens includesourceInSymbolFile ist false.
Die Ressourcenrichtlinie außer Kraft setzen
Es kann eine Ressourcenaussetzung außer Kraft gesetzt werden, um den Benutzern dynamisch Zugriff zu gewähren. Die Richtlinie außer Kraft zu setzen, ist hilfreich, wenn Sie zum Beispiel das Kennzeichen allowDebugging in Ihrer App.json-Datei auf „false“ gesetzt haben, aber bestimmte Microsoft Entra ID-Mandantenzugriffe temporär zulassen möchten. Wenn Sie im unten beschriebenen Geheimnis BC-ResourceExposurePolicy-Overrides nichts angeben, kann niemand Ihren Code debuggen, wenn allowDebugging auf „false“ gesetzt ist. Wenn Sie im Gegenteil allowDebugging in Ihrer app.json-Datei auf true setzen, ist es nicht von Bedeutung, was Sie in dem Geheimnis BC-ResourceExposurePolicy-Overrides festlegen. Jeder wird diesen Code debuggen können.
Es ist erforderlich, dass Sie einen Schlüsseltresor eingerichtet haben, um das Überschreiben der Ressourcenrichtlinie zu aktivieren. Beim Einrichten eines Schlüsseltresors handelt es sich um einen Onboarding-Prozess, der in den folgenden Links beschrieben wird. Befolgen Sie die Richtlinien zur sicheren Aufbewahrung Ihres Schlüsseltresors. Wenn der Schlüsseltresor für mehrere Zwecke genutzt wird, können Sie verschiedene Zugriffsrichtlinien erstellen, um das Geheimnis im Schlüsseltresor außer Kraft zu setzen.
Außerkraftsetzungen von Richtlinien zur Ressourcenoffenlegung können verwendet werden, um Benutzern einer bestimmten Microsoft Entra ID-Mandanten-ID dynamisch Zugriff zu gewähren. Bei den Benutzern, die die Aktion ausführen, z. B. das Debuggen, kann es sich um delegierte Administratoren oder Gastbenutzer in der Zielumgebung handeln. Zudem müssen Sie die Mandanteneigenschaft in der launch.json-Datei angeben. Die Mandanteneigenschaft muss auf die Zielmandanten-ID eingerichtet werden.
Das Geheimnis BC-ResourceExposurePolicy-Overrides
Sobald der Schlüsseltresor eingerichtet ist, kann die Richtlinie einer Erweiterung außer Kraft gesetzt werden, indem die Einstellungen im Schlüsseltresor Ihrer Erweiterung genutzt werden. Dem Schlüsseltresor muss ein Geheimnis namens BC-ResourceExposurePolicy-Overrides hinzugefügt werden. Der Wert des Geheimnisses ist eine .json-Datei mit der im folgenden Beispiel dargestellten Struktur.
$json = '{
"allowDebugging": [
"9e2b6561-1ba6-4790-abcc-c84abf9a8961"
],
"allowDownloadingSource": [
"9e2b6561-1ba6-4790-abcc-c84abf9a8961"
],
"includeSourceInSymbolFile": [
"9e2b6561-1ba6-4790-abcc-c84abf9a8961"
]
}'
$Secret = ConvertTo-SecureString -String $json -AsPlainText -Force
Set-AzKeyVaultSecret -VaultName "YourKeyVaultName" -Name "BC-ResourceExposurePolicy-Overrides" -SecretValue $Secret
Da sich der geheime JSON-Wert in diesem Fall über mehrere Zeilen erstreckt, müssen Sie Azure PowerShell anstelle des Azure-Portals verwenden, um den geheimen JSON-Wert festzulegen. Sie müssen die Mandanten-ID hinzufügen, um diese Eigenschaft für die Benutzer des Mandanten zu aktivieren, Um eine oder mehrere Eigenschaften für die Verwendung durch einen Microsoft Entra ID-Mandanten zu aktivieren. Dadurch wird ein Zugriff auf den Quellcode aktiviert, zum Beispiel für Zwecke des Debuggens.