UrlIdentityPermission Class
Assembly: mscorlib (in mscorlib.dll)
[SerializableAttribute] [ComVisibleAttribute(true)] public ref class UrlIdentityPermission sealed : public CodeAccessPermission
/** @attribute SerializableAttribute() */ /** @attribute ComVisibleAttribute(true) */ public final class UrlIdentityPermission extends CodeAccessPermission
SerializableAttribute ComVisibleAttribute(true) public final class UrlIdentityPermission extends CodeAccessPermission
Not applicable.
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/.
Important: |
|---|
| 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. In 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. In 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.
Caution: |
|---|
| UrlIdentityPermission grants permission for all paths to the file, including both the URL and the IP address. To Deny access to the file, you must Deny all possible paths to the file. For example, if http://www.fourthcoffee.com/process/grind.htm is located at IP address 192.168.238.241, to Deny access to http://www.fourthcoffee.com/process/grind.htm, you must Deny http://www.fourthcoffee.com/process/grind.htm, 192.168.238.241/grind.htm and any other path that you can use to access the code. Unfortunately, there are a myriad of ways URL paths can be phrased, so it is extremely difficult to block all paths through the use of Deny alone. A better technique to deal with multiple paths is to use a combination of PermitOnly and Deny. PermitOnly allows you to identify a finite set of URLs that you can provide access to, and then Deny allows you to explicitly select addresses from that set that you want to deny access to. For more information on this subject and the use of PermitOnly with Deny, see Canonicalization Problems Using Deny in the [<topic://cpcondeny>] topic. |
Note: |
|---|
| In the .NET Framework versions 1.0 and 1.1, identity permissions cannot have an Unrestricted permission state value. In the .NET Framework version 2.0, identity permissions can have any permission state value. This means that in version 2.0, identity permissions have the same behavior as permissions that implement the IUnrestrictedPermission interface. For information on executing version 2.0 applications with version 1.1 CAS policy, see <legacyV1CASPolicy>. |
The following code example shows the behavior of the UrlIdentityPermission class methods.
Note: |
|---|
| The code example is intended to show the behavior of the methods, not to demonstrate their use. In general, the methods of permission classes are used by the security infrastructure; they are not typically used in applications. Generally, only the constructors are used in application code. The created instance validates or controls resource access by using inherited CodeAccessPermission methods such as Demand. |
System.Security.CodeAccessPermission
System.Security.Permissions.UrlIdentityPermission
Windows 98, Windows Server 2000 SP4, Windows Millennium Edition, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition
The Microsoft .NET Framework 3.0 is supported on Windows Vista, Microsoft Windows XP SP2, and Windows Server 2003 SP1.
Important: