.NET中到底什么情况下会抛出SecurityException？
已经给出了简短的答案。我正在寻找长答案。子问题：
- 完全信任的应用程序会抛出 SecurityException 吗？如果是，在什么情况下？
- 什么是“CRL 安全设置”？它们在哪里？我需要担心它们多少？
- 在例如
int.Parse("25")中捕获 ArgumentException 是没有意义的。我什么时候可以确定永远不会抛出 SecurityException？
The short answer has been given already. I'm looking for the long answer. Subquestions:
- Will a full trust application ever throw a SecurityException? If yes, in what circumstances?
- What are "CRL security settings", where are they, and how much do I have to worry about them?
- It's pointless to catch an ArgumentException in e.g.
int.Parse("25"). When can I be sure that a SecurityException will never be thrown?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
要获得最完整的答案，我建议下载共享源 Rotor 并搜索引发
SecurityException的位置。这是一个下载站点： http://www.microsoft.com/downloads/en/details.aspx?FamilyId=8C09FD61-3F26-4555-AE17-3121B4F51D4D&displaylang=en
以及一些示例结果：
HttpWebRequest.CheckResubmit，如果WebPermission上的Demand()失败BaseConfigurationRecord.CheckPermissionAllowed，如果Demand()对于>ConfigurationPermission(PermissionState.Unrestrictred)在某些情况下会失败（还有更多）
...
For the fullest answer, I recommend downloading the shared-source Rotor and searching for places where a
SecurityExceptionis thrown.Here's a download site: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=8C09FD61-3F26-4555-AE17-3121B4F51D4D&displaylang=en
And some sample findings:
HttpWebRequest.CheckResubmit, ifDemand()onWebPermissionfailsBaseConfigurationRecord.CheckPermissionAllowed, ifDemand()for aConfigurationPermission(PermissionState.Unrestrictred)fails in certain circumstances(there are many more)
...
这不是一个全面的答案，但如果组成 Web 应用程序的文件的 NTFS 权限不允许访问针对运行 Web 应用程序的应用程序池设置的标识，则完全信任的 ASP.net 应用程序将引发 SecurityException。您会得到一个非常令人困惑的异常，看起来应用程序即使在完全信任的情况下也没有完全信任。您根本无法保证永远不会抛出安全异常，因为它取决于环境而不是您可能编写的任何代码。例如，两台不同服务器上的完全相同的代码，其中一台可能会抛出 SecurityException，而另一台则可能不会。
It is not a comprehensive answer but a full trust ASP.net application will throw a SecurityException if the NTFS permissions on the files that make up the web app do not allow access to the identity set against the app pool the web app is running under. You get a very confusing exception that looks like the app does not have full trust even when it does. You simply cannot guarantee a security exception will never be throw because it is dependent on the environment not any code you may write. e.g. the exact same code on 2 different servers, one may throw a SecurityException the other may not.