System.Security.Permissions.UrlIdentityPermission Class

Defines the identity permission for the URL from which the code originates. This class cannot be inherited.

See Also: UrlIdentityPermission Members

Syntax

[System.Runtime.InteropServices.ComVisible(true)]
public sealed class UrlIdentityPermission : System.Security.CodeAccessPermission, IBuiltInPermission

Remarks

The complete URL is considered, including the protocol (HTTP, HTTPS, FTP) and the file. For example, http://www.fourthcoffee.com/process/grind.htm is a complete URL.

URLs can be matched exactly or by a wildcard in the final position, for example: http://www.fourthcoffee.com/process/*. URLs can also contain a wildcard ("*") prefix at the dot delimiter. For example, the URL name string http://www.fourthcoffee.com/process/grind.htm/ is a subset of http://*.fourthcoffee.com/process/grind.htm/ and http://*.com/process/grind.htm/.

Note:

Starting with the net_v40_long, identity permissions are not used.

In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. Starting with the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. That is, a demand for an identity always succeeds, regardless of the identity of the assembly, if the assembly has been granted full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case.

In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. Starting with the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case.

Note:

In versions of the .NET Framework before the net_v40_long, you could use the System.Security.CodeAccessPermission.Deny method to prevent inadvertent access to system resources by trusted code. System.Security.CodeAccessPermission.Deny is now obsolete, and access to resources is now determined solely by the granted permission set for an assembly. To limit access to files, you must run partially trusted code in a sandbox and assign it permissions only to resources that the code is allowed to access. For information about running an application in a sandbox, see How To: Run Partially Trusted Code in a Sandbox.

Note:

In the .NET Framework versions 1.0 and 1.1, identity permissions cannot have an PermissionState.Unrestricted permission state value. Starting with the .NET Framework version 2.0, identity permissions can have any permission state value. This means that in 2.0 and later versions, identity permissions have the same behavior as permissions that implement the System.Security.Permissions.IUnrestrictedPermission interface.

Requirements

Namespace: System.Security.Permissions
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 1.0.5000.0, 2.0.0.0, 4.0.0.0