ASP.Net 中等信任设置
我正在尝试将 IPermission 节点配置为中等信任的一部分。 但是，我无法在节点上找到 PathDiscovery 属性的有效值列表，
<IPermission class="FileIOPermission" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$"/>
我需要设置权限，以便帐户能够访问主路径下的所有子目录。 目前，.svc（WCF 服务文件）会引发 404 错误，因为 ASP.Net 帐户无法从几层深度的子文件夹中获取它。 我试图避免将节点更改为
<IPermission class="FileIOPermission" version="1" Unrestricted="true"/>
Any ideas?
TIA
I am trying to configure the IPermission node as part of medium trust. However I am unable to find the valid values list for the PathDiscovery attribute on the node
<IPermission class="FileIOPermission" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$"/>
I need to set the permission so that the account will be able to access all subdirectories under the main path. currently a .svc (WCF service file) throws a 404 error because the ASP.Net account is not able to get it from a sub-folder couple of levels deep. I am trying to avoid changing the node to
<IPermission class="FileIOPermission" version="1" Unrestricted="true"/>
Any ideas?
TIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我当然同意您不应该将节点更改为不受限制，因为这几乎会破坏部分信任的目的。
根据 System.Security.Permissions.FileIOPermission 文档MSDN，FileIOPermission 也应该暗示对该路径下的所有内容的权限。
来自该文档：
当然，微软对构建自定义信任 .config 文件的记录非常糟糕，因此 FileIOPermission 的 .config 标记的行为可能与代码类不同......但这对我来说是令人惊讶的。
是否有可能是其他问题导致了 404？ 仔细检查服务是否正在您期望的凭据下执行，并且路径是否正在正确评估...
I certainly agree that you shouldn't change the node to Unrestricted, as that would pretty much defeat the purpose of partial trust.
According to the System.Security.Permissions.FileIOPermission documentation on MSDN, FileIOPermission is supposed to imply permissions to everything below that path as well.
From that doc:
Of course, building custom trust .config files is woefully poorly documented by Microsoft, so it's possible that the .config markup for FileIOPermission behaves differently than the code class... That would be surprising to me though.
Is it possible some other problem is causing the 404? Double-check that the service is executing under the credentials you'd expect, and that the path is being evaluated correctly...