Modifier

Partager via


SqlClientPermission.Add(String, String, KeyRestrictionBehavior) Method

Definition

Adds a new connection string and a set of restricted keywords to the SqlClientPermission object.

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)

Parameters

connectionString
String

The connection string.

restrictions
String

The key restrictions.

behavior
KeyRestrictionBehavior

One of the KeyRestrictionBehavior enumerations.

Remarks

Use this method to configure which connection strings are allowed by a particular permission object. For example, use the following code fragment if you want to only allow a specific connection string and nothing else:

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

The following example allows connection strings that use any database, but only on the server named MyServer, with any user and password combination and containing no other connection string keywords:

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

Warning

Microsoft does not recommend providing your user name and password directly, because it's an insecure pattern. Where possible, use more secure authentication flows, such as Managed Identities for Azure resources, or Windows authentication for SQL Server.

The following example uses the same scenario as the previous one, but allows for a failover partner that can be used when connecting to servers configured for mirroring:

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

Note

When using code access security permissions for ADO.NET, the correct pattern is to start with the most restrictive case (no permissions at all) and then add the specific permissions that are needed for the particular task that the code needs to perform. The opposite pattern, starting with all permissions and then trying to deny a specific permission, is not secure, because there are many ways of expressing the same connection string. For example, if you start with all permissions and then attempt to deny the use of the connection string "server=someserver", the string "server=someserver.mycompany.com" would still be allowed. By always starting by granting no permissions at all, you reduce the chances that there are holes in the permission set.

Applies to

See also