MVC SiteMap提供商安全性整理+缓存 [英] MVC SiteMap Provider Security Trimming + Cache

查看:50
本文介绍了MVC SiteMap提供商安全性整理+缓存的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经在ASP.NET MVC项目中设置了MVC SiteMap Provider,以呈现下拉菜单.我将其配置为使用安全修整

I have setup MVC SiteMap Provider in an ASP.NET MVC project to render a Dropdown Menu. I configured it to use Security Trimming

<add key="MvcSiteMapProvider_SecurityTrimmingEnabled" value="true"/>

它按预期方式工作,即在用户无权访问的菜单中不显示节点.但是,我正在调试该应用程序,可以看到每次重新加载页面时,AuthorizeAttribute中的断点被命中X + 1次,其中X是菜单中呈现的节点数(+1是实际的节点数.HTTP请求).

It works as expected, i.e., does not show nodes in the menu to which the user does not have access to. However, I am debugging the application and I can see that with each page reload, the breakpoint in the AuthorizeAttribute is being hit X+1 times, where X is the number of nodes that are rendered in the menu (the +1 is the actual HTTP request).

默认情况下,缓存持续时间参数设置为5分钟.我还尝试在Web.config中显式设置参数(以防万一)

By default, the cache duration parameter is set to 5 minutes. I have also tried explicitly setting the parameter in the Web.config (just in case)

<add key="MvcSiteMapProvider_CacheDuration" value="60" />

似乎在安全上下文中未启用缓存.

It looks like caching is not enabled in the security context.

看到这则旧文章(从2010年开始)说要实现缓存.有人可以告诉我现在怎么样吗?

I saw this old post (from 2010) saying that caching was to be implemented. Can somebody tell me how it is by now?

谢谢.

推荐答案

由于没有内置的用户缓存,因此在请求之间存储页面可访问性设置不切实际,更不用说缓存这些设置了它们与当前上下文不同步(例如,如果用户注销).无需进行额外的工作来同步缓存和当前应用程序状态,缓存安全设置始终为黑客提供了一种规避安全性的简便方法.

Since there is no built-in user cache, it wouldn't be practical to store page accessibility settings between requests, not to mention caching these settings could potentially put them out of sync with the current context (for example, if the user logs off). Without doing extra work to sync the cache and the current application state, caching security settings always provides an easy way for a hacker to circumvent security.

因此,每个请求的每个节点都将AuthorizeAttribute调用一次.请记住,MVC仅与当前页面有关,但是MvcSiteMapProvider必须检查所有页面的安全性以确定要显示和隐藏的节点.但是,使用默认的AuthorizeAttribute时,v4中的安全修整性能已得到相当大的提高.进行请求缓存是为了确保每个请求每个节点不会被多次调用.

So the AuthorizeAttribute is called one time per node on each request. Keep in mind that MVC only concerns itself with the current page, but MvcSiteMapProvider must check security for all of the pages in order to determine what nodes to show and hide. However, security trimming performance has been improved considerably in v4 when using the default AuthorizeAttribute. Request caching is done to ensure it is not called more than once per node per request.

如果已对

If you have made customizations to AuthorizeAttribute, you should take care to make the check as quick as possible and to delegate any response action to a handler (the same way Microsoft does) instead of doing so inside of the custom AuthorizeAttribute.

与MvcSiteMapProvider一起使用自定义AuthorizeAttribute的一个限制是,必须在授权成功时将actionContext.Response值设置为null,而在授权失败时将其设置为非null.

The one constraint of using a custom AuthorizeAttribute with MvcSiteMapProvider is that it must set the actionContext.Response value to null when authorization succeeds and a non-null value when it fails.

这篇关于MVC SiteMap提供商安全性整理+缓存的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆