Impostazione dei criteri di esposizione delle risorse
Quando si avvia un nuovo progetto, si genera automaticamente un file app.json, che contiene le informazioni sull'estensione che si sta sviluppando.
Nel file app.json è possibile specificare un'impostazione denominata resourceExposurePolicy che definisce l'accessibilità delle risorse e del codice sorgente durante varie operazioni.
resourceExposurePolicy specifica il seguente elenco di opzioni:
applyToDevExtension
allowDebugging
allowDownloadingSource
includeSourceInSymbolFile
Ognuna di queste proprietà definisce le aree specifiche in cui è possibile accedere al codice sorgente di un'estensione. Per impostazione predefinita, tutte le opzioni sono impostate su false. Ciò significa che per impostazione predefinita nessuna estensione dipendente può eseguire il debug o il download del codice sorgente dell'estensione.
La sintassi dell'impostazione resourceExposurePolicy è la seguente:
`"resourceExposurePolicy": {"applyToDevExtension": <boolean>, "allowDebugging": <boolean>, "allowDownloadingSource": <boolean>, "includeSourceInSymbolFile": <boolean>}`
Il modello di progetto AL:Go! ora contiene allowDebugging, allowDownloadingSource e includeSourceInSymbolFile attivati per impostazione predefinita. Questo è visibile nel file app.json in cui è impostata la proprietà resourceExposurePolicy del progetto.
È sempre possibile eseguire l'override di questa impostazione per l'estensione per tenant o AppSource modificando l'impostazione.
Il modello AL: Go! imposta su true le opzioni allowDebugging, allowDownloadingSource e includeSourceInSymbolFile nell'impostazione resourceExposurePolicy.
applyToDevExtension
Con il flag applyToDevExtension è possibile specificare se tutti i criteri di esposizione delle risorse specificati per l'estensione si applicano anche alle estensioni per sviluppatori, impostando il valore su true.
allowDebugging
Per consentire il debug nell'estensione, è necessario impostare il flag allowDebugging quando l'estensione viene considerata una dipendenza. In caso contrario, il debug non è consentito. Il valore predefinito di allowDebugging è false.
Se si desidera consentire il debugging nell'estensione per visualizzare il codice sorgente, è necessario impostare su true la proprietà allowDebugging nel file app.json. Ad esempio, se uno sviluppatore sviluppa un'estensione A e un altro sviluppa un'estensione B, dove B dipende da A, il debug di B accederà solo al codice per A se si chiama un metodo da A e se il flag allowDebugging è impostato su true nel file app.json per l'estensione A, come mostra l'esempio di seguito. Aggiungendo questa impostazione, si abilita il debug in un'estensione per visualizzare il codice sorgente e le variabili quando quell'estensione è impostata come dipendenza.
"resourceExposurePolicy": {"allowDebugging": true}
allowDebugging non si applica a Profili, Personalizzazioni pagina e Visualizzazioni perché questi oggetti non possono definire logica personalizzata nelle procedure o nei trigger. È anche possibile accedere al codice per Profili, Personalizzazioni pagina e Visualizzazioni definito in un'estensione con allowDebugging impostato su false e copiarlo usando Designer.
Attributo [NonDebuggable]
A meno che non si sia specificato l'attributo [NonDebuggable] per metodi e variabili, impostare la proprietà allowDebugging su true per accedere a questo codice. Se, invece, si sono contrassegnati i metodi e le variabili con l'attributo [NonDebuggable], non sarà possibile sottoporre a debug questi metodi e variabili.
Il valore predefinito del flag allowDebugging è false. Se allowDebugging è impostato su true, chiunque estenda il codice può eseguirne il debug.
Tuttavia, non è possibile consentire sia il debug sia Vai alla definizione e impedire che il codice sorgente venga estratto tramite l'esperienza di debug, ad esempio usando strumenti di Visual Studio Code di terze parti. Per le app AppSource, se si desidera proteggere l'IP, è consigliabile limitare l'accesso alla sorgente impostando i flag resourceExposurePolicy su false. Approfittare quindi della possibilità di concedere a se stessi e, se lo si desidera, ai partner rivenditori di fiducia un accesso singolo e a tempo limitato attraverso l'override dinamico dei criteri delle risorse.
Per le estensioni per tenant, se il cliente è proprietario dell'IP e ne approva l'esposizione, è consigliabile consentire almeno il debug e includere l'origine nei simboli per semplificare la risoluzione dei problemi, l'estrazione dell'IP dal servizio e la gestione dei diversi rivenditori.
Qualcuno sarà ancora in grado di visualizzare il codice se un'estensione viene distribuita attraverso Visual Studio Code come estensione DEV anziché tramite un cmdlet, usando la pagina Gestione estensioni in Business Central o AppSource. Usare l'impostazione applyToDevExtension per specificare se tutti i criteri di esposizione delle risorse devono applicarsi anche all'estensione DEV.
allowDownloadingSource
Quando questo flag è impostato su true nel file app.json dell'estensione A, è possibile scaricare il codice sorgente e tutti i file multimediali dell'estensione A, ad esempio dall'opzione Scarica origine nella pagina Gestione estensioni in Business Central. L'estensione A può essere un'estensione PTE o DEV. Il valore predefinito di allowDownloadingSource è false.
includeSourceInSymbolFile
Quando questo flag è impostato su true nel file app.json dell'estensione A, il file di simboli scaricato in Visual Studio Code, accessibile usando la funzionalità Download dei simboli, contiene simboli, codice sorgente e tutte le altre risorse dell'estensione A. Quando includeSourceInSymbolFile è impostato su false, l'origine non è disponibile nei file di simboli e non è possibile usare Vai alla definizione per visualizzare l'origine. È comunque possibile estendere la funzionalità, ottenere IntelliSense per essa e chiamarla nell'estensione A basandosi sui simboli e sulle firme esposti. Il valore predefinito di includesourceInSymbolFile è false.
Override dei criteri delle risorse
È possibile eseguire l'override dell'esposizione delle risorse per concedere l'accesso agli utenti in modo dinamico. L'override dei criteri è utile, ad esempio, se si è impostato il flag allowDebugging su false nel file app.json, ma si vuole concedere l'accesso temporaneo a tenant di Microsoft Entra ID specifici. Se non si specifica nulla nel segreto BC-ResourceExposurePolicy-Overrides descritto di seguito, nessuno può eseguire il debug del codice se allowDebugging è impostato su false. Al contrario, se si è impostato allowDebugging su true nel file app.json, ciò che si specifica nel segreto BC-ResourceExposurePolicy-Overrides non è importante. Chiunque sarà in grado di eseguire il debug in quel codice.
È necessario abilitare l'override dei criteri delle risorse, per cui si dispone di un insieme di credenziali delle chiavi impostato. L'impostazione di un insieme di credenziali delle chiavi è un processo di onboarding descritto nei collegamenti seguenti. Seguire le linee guida per mantenere sicuro l'insieme di credenziali delle chiavi. Se si usa l'insieme di credenziali delle chiavi per più scopi, è possibile creare criteri di accesso diversi per eseguire l'override del segreto nell'insieme di credenziali delle chiavi.
È possibile eseguire l'override dei criteri di esposizione delle risorse per concedere l'accesso agli utenti di un determinato ID tenant Microsoft Entra ID. Gli utenti che eseguono l'azione, ad esempio il debug, possono essere amministratori con delega o utenti guest nell'ambiente di destinazione. È inoltre necessario specificare la proprietà del tenant nel file launch.json. È necessario impostare la proprietà del tenant sull'ID tenant di destinazione.
Segreto BC-ResourceExposurePolicy-Overrides
Dopo aver impostato l'insieme di credenziali delle chiavi, è possibile eseguire l'override dei criteri di un'estensione usando le impostazioni nell'insieme di credenziali delle chiavi dell'estensione. È necessario aggiungere un segreto denominato BC-ResourceExposurePolicy-Overrides all'insieme di credenziali delle chiavi. Il valore del segreto è un file .json con la struttura mostrata nell'esempio seguente.
$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
Poiché in questo caso il valore del segreto json si estende su più righe, è necessario usare Azure PowerShell anziché il portale di Azure per definire il valore del segreto json. Per abilitare una o più proprietà per l'uso da parte di un tenant Microsoft Entra ID, è necessario aggiungere l'ID tenant per abilitare quella proprietà per gli utenti del tenant. In questo modo, si abilita un accesso temporaneo al codice sorgente, ad esempio per scopi di debug.