SqlClientPermission.Add(String, String, KeyRestrictionBehavior) Méthode

Définition

Ajoute une nouvelle chaîne de connexion et un ensemble de mots clés restreints à l'objet SqlClientPermission.

public:
 override void Add(System::String ^ connectionString, System::String ^ restrictions, System::Data::KeyRestrictionBehavior behavior);
public override void Add (string connectionString, string restrictions, System.Data.KeyRestrictionBehavior behavior);
override this.Add : string * string * System.Data.KeyRestrictionBehavior -> unit
Public Overrides Sub Add (connectionString As String, restrictions As String, behavior As KeyRestrictionBehavior)

Paramètres

connectionString
String

Chaîne de connexion

restrictions
String

Restrictions clés.

behavior
KeyRestrictionBehavior

Une des énumérations KeyRestrictionBehavior.

Remarques

Utilisez cette méthode pour configurer les chaînes de connexion autorisées par un objet d’autorisation particulier. Par exemple, utilisez le fragment de code suivant si vous souhaitez autoriser uniquement un chaîne de connexion spécifique et rien d’autre :

permission.Add("server=MyServer; database=MyDatabase; Integrated Security=true", "", KeyRestrictionBehavior.AllowOnly)

L’exemple suivant autorise les chaînes de connexion qui utilisent n’importe quelle base de données, mais uniquement sur le serveur nommé MyServer, avec n’importe quelle combinaison d’utilisateur et de mot de passe et ne contenant aucun autre mot clé chaîne de connexion :

permission.Add("server=MyServer;", "database=; user id=; password=;", KeyRestrictionBehavior.AllowOnly)

L’exemple suivant utilise le même scénario que ci-dessus, mais autorise un partenaire de basculement qui peut être utilisé lors de la connexion à des serveurs configurés pour la mise en miroir :

permission.Add("server=MyServer; failover partner=MyMirrorServer", "database=; user id=; password=;", KeyRestrictionBehavior.AllowOnly)

Notes

Lorsque vous utilisez des autorisations de sécurité d’accès du code pour ADO.NET, le modèle approprié consiste à commencer par le cas le plus restrictif (aucune autorisation du tout), puis à ajouter les autorisations spécifiques nécessaires à la tâche particulière que le code doit effectuer. Le modèle inverse, en commençant par toutes les autorisations, puis en essayant de refuser une autorisation spécifique, n’est pas sécurisé, car il existe de nombreuses façons d’exprimer les mêmes chaîne de connexion. Par exemple, si vous démarrez avec toutes les autorisations, puis refusez l'utilisation de la chaîne de connexion "server=someserver", vous pouvez continuer à utiliser "server=someserver.mycompany.com". En démarrant toujours en n'accordant aucune autorisation, vous limitez les risques de failles dans le jeu d'autorisations.

S’applique à

Voir aussi