Modificatori di accesso
I modificatori di accesso sono un nuovo costrutto introdotto in ThingWorx 9.5 per consentire agli sviluppatori di identificare gli elementi (entità e relative caratteristiche) protetti dall'uso esterno e quelli che possono essere utilizzati dagli utenti finali per un'ulteriore personalizzazione o sviluppo, tra cui estensione, riferimenti e riutilizzo. Esiste anche la possibilità di avere entità aperte utilizzabili esternamente ma con alcune caratteristiche protette.
L'accesso agli elementi protetti viene controllato in fase di esecuzione, quando viene fornito l'accesso per l'utilizzo. La maggior parte delle relazioni definite formalmente viene convalidata al momento della creazione. Tuttavia, l'utilizzo all'interno di blocchi di codice di servizi e mashup viene verificato solo in fase di esecuzione. I controlli in fase di esecuzione sono soggetti a errore, pertanto vanno considerati come un supporto utile per evitare un uso improprio. La dichiarazione del modificatore di accesso rimane la fonte dati di riferimento e gli sviluppatori devono attenersi al divieto di utilizzare gli elementi protetti in questione in violazione dei modificatori di accesso dichiarati. Tali elementi protetti possono essere modificati o rimossi e qualsiasi utilizzo dipendente non consentito potrebbe iniziare a restituire errore in qualsiasi momento, senza preavviso.
Un modificatore di accesso specifica l'ambito di accessibilità per entità e caratteristiche.
In ThingWorx 9.5.0 il modificatore di accesso è supportato per le entità e le caratteristiche riportate di seguito.
|
Entità
|
Caratteristiche
|
||||
|---|---|---|---|---|---|
|
• Oggetti
• Modelli di oggetto
• Thing shape
• Gruppi di oggetti
• Data shape
• Reti
• Connessioni industriali
• Connettori di integrazione
• Scheduler
• Timer
• Dashboard
• Menu
• Entità multimediali
• Definizioni di stile
• Temi stile
• Definizioni di stato
• Tabella dati
• Stream
• Stream di valori
• Blog
• Wiki
|
• Proprietà
• Servizio
• Tabella di configurazione
|
Il modificatore di accesso non è supportato dalle seguenti entità:
|
• Progetto
• Tag modello
• Notifica
• Tag dati
• Provider di persistenza
• Gruppi di utenti
• Utenti
• Organizzazioni
• Chiavi di accesso
• Servizi di elenco
• Autenticatori
• Mashup
• Modello di mashup
• Master
• Gadget
• Tabelle di localizzazione
|
I modificatori di accesso sono suddivisi nelle seguenti categorie:
• NESSUNO: l'assenza di ambito viene considerata come ambito pubblico e può essere applicata a un'entità o a una caratteristica. L'accesso alle entità e alle caratteristiche con ambito pubblico è consentito a tutti.
◦ L'accesso alle entità con ambito NONE è consentito a tutti.
◦ La caratteristica con ambito NONE eredita il modificatore di accesso dall'entità a cui appartiene.
• PRIVATO: può essere applicato a un'entità o alle caratteristiche ed è possibile accedervi solo all'interno del progetto.
• LIMITATO: può essere applicato a un'entità o alle caratteristiche. Si comporta come un ambito privato, aggiungendo i progetti con il namespace e la relativa gerarchia figlio all'elenco dei progetti accessibili. Ad esempio, RESTRICTED[ptc.dpm.jobOrder] è accessibile per tutte le entità dal namespace ptc.dpm.jobOrder e dai namespace figli, ma è privato per tutte le altre entità.
 |
In ThingWorx 9.5.0 è possibile aggiungere un solo namespace (e naturalmente i figli) per l'ambito Limitato.
|
• Interno: questo ambito può essere applicato solo alle caratteristiche, che diventano accessibili solo all'interno dell'entità.
|
|
Le assegnazioni degli ambiti vengono rese persistenti per entità e caratteristiche.
L'ambito può essere applicato a tutte le entità supportate, indipendentemente dal tipo di progetto. Se a un progetto non è assegnato un namespace, è possibile applicare solo gli ambiti Nessuno o Privato alle entità e Nessuno, Privato o Interno alle caratteristiche.
|
|
|
Dopo la migrazione a ThingWorx 9.5, tutte le entità e le caratteristiche avranno ambito NONE (assente).
|
• L'ambito delle caratteristiche non può essere più ampio di quello dell'entità. Ad esempio, se l'ambito dell'entità è PRIVATO, le caratteristiche non possono avere un ambito NESSUNO.
• Per gli oggetti associati a un'entità con ambito NESSUNO, l'ambito degli oggetti dell'elenco LIMITATO a livello di caratteristica deve essere più ampio, uguale o più ristretto. E per le entità con altri ambiti, l'ambito per gli oggetti dell'elenco LIMITATO a livello di caratteristica deve essere uguale o più ristretto.
Requisiti per la creazione di un ambito
Il nome di un ambito deve includere solo lettere maiuscole.
Configurazione di un ambito di default per i progetti di tipo Building block
È possibile configurare un ambito di default per i progetti di tipo Building block. Quando si crea una nuova entità, questa configurazione viene utilizzata come assegnazione di default per l'ambito.
L'ambito di default di un progetto può essere aggiornato in fase di esecuzione tramite Composer o una chiamata REST. Le nuove entità che vengono create in questo progetto erediteranno questo ambito. La modifica di questa configurazione non influisce sull'ambito delle entità esistenti. L'ambito di un'entità può essere modificato in fase di esecuzione.
|
|
Questa configurazione si applica alle impostazioni dell'ambito solo quando si utilizza Composer per la creazione di entità
|
Impostazione di un modificatore di accesso su un'entità o sulle caratteristiche
Un modificatore di accesso può essere assegnato a un'entità o alle caratteristiche nei modi descritti di seguito.
• Selezionando l'ambito dall'elenco Ambito nella scheda Informazioni generali in Composer.
• Utilizzando le annotazioni Java
• Importando estensioni o XML.
• Eseguendo il servizio SetAccessModifier nella risorsa EntityServices. Questo servizio può essere utilizzato per impostare un modificatore di accesso per più entità e caratteristiche in blocco.
|
|
In ThingWorx 9.5.0 l'impostazione di un modificatore di accesso dalla chiamata di creazione di servizi nella risorsa EntityServices non è supportata. Ad esempio, la creazione di servizi come CreateThing, CreateThingShape, CreateNetwork e così via non accetta come argomento il modificatore di accesso.
|
|
|
Durante la creazione di un'entità, i modificatori di accesso non vengono registrati nei log verifiche.
|
|
|
I modificatori di accesso possono essere aggiunti alle caratteristiche tramite annotazioni Java. Tuttavia, per aggiungere modificatori di accesso a livello di entità non è disponibile il supporto per le annotazioni. È possibile aggiungere i modificatori di accesso a livello di entità tramite l'importazione XML.
|
Visualizzazione di un modificatore di accesso impostato su un'entità o sulle caratteristiche
Eseguendo il servizio GetAspects nelle risorse EntityServices, è possibile visualizzare il modificatore di accesso impostato per un'entità o per le caratteristiche.
Filtraggio di entità tramite i modificatori di accesso
È possibile filtrare le entità in base all'ambito utilizzando 
in Composer.
in Composer.
Registrazione dei modificatori di accesso
Se un utente crea, aggiorna o elimina i modificatori di accesso impostati per un'entità o per le caratteristiche, le verifiche vengono mantenute nel Log verifiche.
Per informazioni, vedere Sottosistema Verifica.
| | Le modifiche a un'entità o a una caratteristica apportate da un'altra entità, da un membro o da chiamate di servizio non vengono sottoposte a verifica. |
Spostamento di entità tra progetti
Quando si sposta un'entità da un progetto a un altro, l'ambito dell'entità, le proprietà, i servizi e le tabelle di configurazione rimangono invariati, se l'ambito dell'entità o della caratteristica di origine è Nessuno o Privato.
| | Un namespace è valido se il suo ambito è uguale o più ampio rispetto a quello del namespace del progetto di destinazione. Se l'ambito del namespace è diverso o più limitato di quello del progetto di destinazione, non è valido. |
Di seguito sono elencati i diversi scenari che possono presentarsi durante lo spostamento delle entità con ambito Limitato da un namespace all'altro.
• Scenario 1
Se il namespace dell'entità è valido, l'ambito non cambia.
Ad esempio, quando un'entità con ambito RESTRICTED [dpm.sco.jobOrder] viene spostata in un progetto con namespace (dpm.sco.jobOrder.scp.jobOrder12), l'ambito dell'entità rimane invariato.
• Scenario 2
Se il namespace dell'entità non è valido e il progetto di destinazione non ha un ambito di default, l'ambito dell'entità diventa privato.
Ad esempio:
◦ Quando un oggetto con ambito RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] viene spostato in un progetto con namespace (abc.xyz.pqr), l'ambito dell'oggetto cambia in PRIVATE[abc.xyz.pqr].
• Scenario 3
Se il namespace dell'entità non è valido e l'ambito di default del progetto di destinazione è Limitato con exmptList, l'ambito dell'entità cambia in quello di default del progetto di destinazione.
Ad esempio:
◦ Quando un oggetto con ambito RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] viene spostato in un progetto il cui ambito di default è RESTRICTED[abc.xyz.pqr], l'ambito dell'oggetto cambia in RESTRICTED[abc.xyz.pqr].
◦ Quando un oggetto con ambito RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] viene spostato in un progetto il cui ambito di default è RESTRICTED[dpm.sco.jobOrder], l'ambito dell'oggetto cambia in RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12].
• Scenario 4
Se il namespace dell'entità non è valido e l'ambito di default del progetto di destinazione è privato, l'ambito dell'entità cambia in quello di default del progetto di destinazione.
Ad esempio:
◦ Quando un oggetto con ambito RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] viene spostato in un progetto il cui ambito di default è PRIVATE[dpm.sco.jobOrder], l'ambito dell'oggetto cambia in PRIVATE[dpm.sco.jobOrder].
◦ Quando un oggetto con ambito RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] viene spostato in un progetto il cui ambito di default è PRIVATE[abc.xyz.pqr], l'ambito dell'oggetto cambia in PRIVATE[abc.xyz.pqr].
• Scenario 5
Se il namespace dell'entità non è valido e il progetto di destinazione non dispone di un namespace, l'ambito dell'entità viene modificato in Privato.
Ad esempio, quando un oggetto con ambito RESTRICTED [dpm.sco.jobOrder.scp.jobOrder12] viene spostato in un progetto senza namespace, l'ambito dell'oggetto cambia in PRIVATE.
| | Se RESTRICTED cambia a livello di entità e l'ambito RESTRICTED delle caratteristiche non è valido, l'ambito delle caratteristiche cambia in Ereditato. |
| | Lo spostamento delle entità viene registrato come Debug nel log applicazioni. |
Limiti dei modificatori di accesso
Di seguito sono riportati i limiti dei modificatori di accesso.
• Durante la creazione di un nuovo servizio o la modifica di un servizio esistente, non vengono visualizzate le caratteristiche ereditate nella sezione Personale/Entità.
• Durante la creazione delle associazioni di proprietà, sono visibili le proprietà private di un altro progetto.
• I mashup non hanno modificatori di accesso.
• Se nel nome dell'entità sono presenti caratteri speciali e i controlli del modificatore di accesso non vengono eseguiti durante l'esecuzione, attenersi alla procedura descritta di seguito.
1. Codificare il nome nel formato Base64.
2. Aggiungere un suffisso nel formato nomecodificato/b64.
3. Passare questo valore come twx-referrer-entity durante l'utilizzo delle API REST.
• Se per un nome di entità sono presenti caratteri diversi da quelli menzionati nel file validation.properties, i controlli del modificatore di accesso non vengono eseguiti durante l'esecuzione. È possibile aggiungere caratteri al file configurando il file validation.properties. Aggiungere o modificate i valori per Validator.HTTPHeaderValue. Per ulteriori informazioni, vedere Configurazione delle impostazioni della convalida ESAPI.