Options de protection et de confidentialité des paramètres personnalisés
Gérez la visibilité et les autorisations des paramètres personnalisés.
Éditions requises
| Disponible avec : Salesforce Classic et Lightning Experience |
Disponible avec : Group Edition, Professional Edition, Developer Edition Enterprise Edition, Performance Edition, Unlimited Edition et Database.com Edition Les packages ne sont pas disponibles dans Database.com |
Packages
Seules les définitions des paramètres sont incluses dans un package, pas les données. Pour inclure des données, complétez les paramètres personnalisés à l'aide d'un script Apex ou API standard exécuté par l'organisation abonnée, une fois le package installé.
Lorsqu'un paramètre personnalisé est inclus dans un package géré et que la visibilité est définie sur Protégé, l'accès est autorisé uniquement avec le code Apex inclus dans ce package géré. Les organisations abonnées ne peuvent pas accéder, lire ou modifier directement les paramètres personnalisés protégés.
Les paramètres personnalisés protégés d'un package non géré fonctionnent comme des paramètres personnalisés publics. Assurez-vous que les secrets, les informations d'identification personnelle ou les données privées sont stockées dans des types de métadonnées personnalisées protégés, installées dans le cadre d'un package géré. Hors d'un package géré, utilisez des identifiants nommés ou des champs personnalisés cryptés pour stocker des secrets tels que des jetons OAuth, des mots de passe ou d'autres données confidentielles.
Visibilité
Vous pouvez créer des paramètres personnalisés protégés dans les organisations Developer et de test. Les options des paramètres personnalisés sont les suivantes :
- Protégé : les paramètres personnalisés d'un package géré sont visibles par l'intermédiaire d'Apex et de formules dans les mêmes package et espace de noms. Cependant, ils ne sont pas visibles par les organisations abonnées via Apex et l'API. Les paramètres personnalisés contenus dans un package non géré se comportent comme des paramètres personnalisés publics et n'offrent aucune protection.
- Public : quel que soit le type de package (géré ou non géré), les éléments suivants ont accès :
- Apex
- Formules
- Flux
- API pour les utilisateurs qui disposent de l'autorisation Personnaliser l'application ou d'autorisations accordées via des profils ou des ensembles d'autorisations.
Paramètres du schéma
Les options de paramètres de schéma pour des paramètres personnalisés sont les suivantes :
- Limiter l'accès aux paramètres personnalisés : cette préférence de l'organisation est activée par défaut et limite l'accès aux valeurs des paramètres personnalisés. Les administrateurs qui disposent de l'autorisation Personnaliser l'application peuvent accorder l'accès Lire à des utilisateurs via des profils et des ensembles d'autorisations avec les autorisations Définitions de paramètres personnalisés ou Afficher tous les paramètres personnalisés.
- Activer SOSL dans les paramètres personnalisés : les valeurs des paramètres personnalisés ne sont pas renvoyées dans les requêtes du langage Salesforce Object Search (SOSL). Si vos opérations Apex nécessitent cette fonctionnalité, activez cette option.
Octroi d'autorisations dans des profils ou des ensembles d'autorisations
La préférence de l'organisation Limiter l'accès aux paramètres personnalisés est activée par défaut, et l'accès Lire aux valeurs des paramètres personnalisés doit être explicitement accordé.
Les administrateurs qui disposent de l'autorisation Personnaliser l'application peuvent accorder l'accès Lire via des profils et des ensembles d'autorisations à des utilisateurs qui n'ont pas l'autorisation Personnaliser l'application.
- Pour accorder l'autorisation à des paramètres personnalisés spécifiques, utilisez l'autorisation Définitions de paramètres personnalisés.
- Pour accorder l'autorisation à tous les paramètres personnalisés, utilisez l'autorisation Afficher tous les paramètres personnalisés.
Comportement Apex, Visualforce et Aura
Dans Salesforce, différents modes de code d'exécution affectent l'accessibilité des paramètres personnalisés.
Un code Apex exécuté en mode système ignore les autorisations utilisateur et votre code Apex a accès à tous les objets et champs. Les autorisations d'objet, la sécurité au niveau du champ et les règles de partage ne sont pas appliquées pour l'utilisateur actif. L'exécution en mode système évite l'échec du code dû à des champs ou à des d'objets masqués pour un utilisateur.
En mode utilisateur, les fonctionnalités telles que les composants Visualforce, les modèles d'e-mail Visualforce et Aura sont exécutées en fonction des autorisations et du partage d'enregistrement de l'utilisateur.
with sharing de la classe Apex n'affecte pas le comportement des requêtes telles que isAccessible() et isCreatable(). Si une valeur de champ est récupérée dans Apex et attribuée à une variable non sObject, ce comportement est identique que la préférence soit activée ou non.Lorsque la fonctionnalité est exécutée en mode utilisateur, par exemple avec des composants Visualforce, des modèles d'e-mail Visualforce et Aura, une autorisation est requise pour accéder aux paramètres personnalisés. Par exemple, sans autorisation, les champs des pages Visualforce auxquelles vous n'avez pas accès ne sont pas affichés. La variable globale $Setup (disponible dans Visualforce et les formules) continue de charger les valeurs par référence directe (ce qui signifie que les données sont attribuées à un type sObject) quel que soit l'utilisateur actif.
Tenez compte du scénario suivant :
- Apex charge un enregistrement, qui est une ligne incluse dans une variable telle que
MySetting__c. - Visualforce affiche
MySetting__c.MyPath__c. - Les contrôles d'accès sont exécutés au chargement de la page.
- Cependant, ils ne sont pas exécutés en mode système, qui est le comportement Visualforce standard. Les utilisateurs sans autorisation d'accès aux paramètres personnalisés ne peuvent pas afficher la page Visualforce, car Visualforce réinitialise le contrôle d'accès.
Dans ce scénario, si un utilisateur n'a pas accès aux paramètres personnalisés, vous avez deux solutions. Vous pouvez créer une chaîne pour chaque objet, qui peut être transmise, ou créer une classe wrapper. Utilisez ces options au lieu d'attribuer une variable telle que MySetting__c, puis de restituer mySetting.Path__c mySetting.Name. Exemple
class DataHolder{
public string path {get;set;}
public boolean active {get;set;}
}Lorsque vous chargez des lignes dans une collection, les contrôles Visualforce sont contournés, car le type est un type de données au lieu d'un sObject.
Voici un exemple qui inclut l'annotation @AuraEnabled pour un contrôleur de composants Aura ou Lightning.
class with sharing MyController {
@AuraEnabled
public static List<My__mdt> thisWillNotWork() {
return [select developername from my__mdt];
}
@AuraEnabled
public static List<String> thisWill() {
List<String> retVal = new List<String>();
for(My__mdt config: [select developername from my__mdt]) {
retVal.add(config.DeveloperName);
}
return retVal;
}
}