CASPOL、FullTrust 以及基于 URL 使用 FullTrust 在 IE 中运行 ActiveX 控件
我已经设置了一个在网页上运行的 Activex 控件。 服务器能够为自己提供该网页，但 Intranet 和 Internet 上的其他计算机无法访问它。
Caspol 设置如下所示：
代码组：
1. All code: FullTrust
1.1. Zone - MyComputer: FullTrust
1.1.1. StrongName - (omitted) : FullTrust
1.1.2. StrongName - 00000000000000000400000000000000: FullTrust
1.2. Zone - Intranet: FullTrust
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.3. Zone - Internet: Internet
1.3.1. All code: Same site Web
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.5.1. All code: Same site Web
1.6. Url - http://MYSERVERNAME/APPLICATIONNAME/*: FullTrust
Success
我尝试访问的应用程序是组 1.6。 我在这里做错了什么吗？
[编辑] 值得一提的是，尝试从 Intranet 访问控件的计算机上的 IEDebug 错误日志会显示很长的异常。 其中最值得一提的是：
System.Net.WebPermission
The first permission that failed was:
<IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1">
I've set up an activex control to run on a webpage. The server is able to serve this webpage to itself, but other machines on the intranet and internet aren't able to access it.
The Caspol settings look like this:
Code Groups:
1. All code: FullTrust
1.1. Zone - MyComputer: FullTrust
1.1.1. StrongName - (omitted) : FullTrust
1.1.2. StrongName - 00000000000000000400000000000000: FullTrust
1.2. Zone - Intranet: FullTrust
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.3. Zone - Internet: Internet
1.3.1. All code: Same site Web
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.5.1. All code: Same site Web
1.6. Url - http://MYSERVERNAME/APPLICATIONNAME/*: FullTrust
Success
The application I'm trying to access is group 1.6. Am I doing something wrong here?
[Edit]
It's worth mentioning that the IEDebug Error Log on a machine attempting to access the control from the intranet displays a long exception. The most noteworthy of it being:
System.Net.WebPermission
The first permission that failed was:
<IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1">
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
很久以前，我在某处读到，对于 .Net 用户控件，Url 证据不起作用。 仅站点和区域证据有效。
您可以对每个区域执行此操作。
使用 IE8 时，请确保将 mysite.com 添加到受信任站点列表 3。 我不确定保护模式是否必须关闭。
当您在 64 位系统上时，有两个 caspol，具有不同的权限：
我花了很多时间在 32 位 caspol 上设置权限，然后用头撞墙，因为它不起作用。 结果我使用了 64 位 IE8，因为它生成了 IEDebug.log。 最好在两个版本上都设置权限。
A long time ago I read somewhere that for .Net usercontrols, Url evidence doesn't work. Only Site and Zone evidence work.
You can do this for each Zone.
When using IE8, make sure mysite.com is added to the Trusted Sites list 3. I'm not sure if Protected Mode has to be off.
When you're on a 64-bit system, there are two caspol's, with separate permissions:
I a lot of time setting permissions on the 32-bit caspol, and then banging my head against the wall because it wouldn't work. Turns out I used 64-bit IE8 because that made a IEDebug.log. Best to set the permissions on both versions.
事实证明，这根本不是信任问题。 应用程序运行所需的 DLL 不在应用程序的 bin 目录中。 因此，应用程序试图从 GAC 中提取所需的 DLL，这是不正确的。 使用所需的 DLL 进行部署解决了该问题。
附带说明一下——这是一种非常过时的软件交付机制，希望不再使用它。 调试这些类型的错误比应有的要困难得多。 建议选择比嵌入式控件更好的交付机制。
As it turns out, this wasn't a trust issue at all. A DLL that was required for the application to run was not in the bin directory of the application. Consequently, the application was attempting to pull the required DLL from the GAC, which wasn't correct. Deploying with the required DLL fixed the issue.
As a side note -- this is a very antiquated delivery mechanism for software and hopefully it's not being used anymore. Debugging these types of errors is much more difficult than it should be. Recommend choosing a better delivery mechanism than embedded controls.