ASP.NET 中的 URL 授权足够安全吗？
我已根据某些角色并使用 URL 授权将页面分类到不同的文件夹中，例如，我在 web.config 中使用以下代码来限制对管理内容的访问：
<configuration>
<system.web>
<authorization>
<allow roles="Admin" />
<allow roles="SuperAdmin" />
<deny roles="Member" />
<deny users="?"/>
</authorization>
</system.web>
</configuration>
我的问题是：这足够安全吗？ 或者我需要做一些其他事情，例如：在每个用户想要执行管理工作的事件中，我应该检查他们是否处于适当的角色？
编辑： 我使用“表单身份验证提供程序”和“ASP.NET 会员资格提供程序”来验证用户和会员身份，据我所知它是安全的
I have categorized my pages in different folders based on some roles and using URL authorization , For example I use the following code in web.config for limiting access to that administrative stuff :
<configuration>
<system.web>
<authorization>
<allow roles="Admin" />
<allow roles="SuperAdmin" />
<deny roles="Member" />
<deny users="?"/>
</authorization>
</system.web>
</configuration>
My question is : Is that enough secure ?
Or I need to do some other things like : in every events which user want to do administrative stuff , I should check If they are in appropriate role ?
Edit:
I use "Forms Authentication Provider" and "ASP.NET Membership Provider" for authenticating users and Membership , And as far as i know it's secure
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这只是验证，没有用户收到任何未经授权的页面。由于您在业务层中执行大量业务操作，因此您还想检查那里的授权。
大多数时候，您也无法避免在页面内部多次检查，因为页面通常会提供不同的内容，具体取决于低权限用户还是高权限用户请求它们。
一般来说，您必须自行决定您所提供的每一条信息——是否可以？如果它不是一般的公共信息：想一想，如何才能有效地限制它？基于 ASP.NET 成员资格类的授权方案是这样做的良好基础。
This does only verify, no user is getting any page delivered, which she is not authorized for. Since you are doing a lot of business stuff in your business layer, you want to check the autorization there also.
Most the time you cant avoid having to check several time inside the page also, since the pages often deliver different content, depending if a low right user or a high right user requests them.
In general you will have to decide on your own for every single information you are giving away - is it ok or not? If it not in general a public information: think about, how could you restrict it effectively? The authorization scheme based on the ASP.NET membership classes is a good base to do so.