基于页面的权限设计原形

权限属性定义:

/// <summary>
    /// 权限属性
    /// </summary>
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
    public class AccessLevAttribute : Attribute
    {
        /// <summary>
        /// 名称
        /// </summary>
        public string Name { get; set; }

        /// <summary>
        /// 权限
        /// </summary>
        public string LevStr { get; set; }

        /// <summary>
        ///
        /// </summary>
        static Type attrType = typeof(AccessLevAttribute);

        public AccessLevAttribute(string name)
        {
            this.Name = name;
        }

        public AccessLevAttribute(string name, string levStr)
        {
            this.Name = name;
            this.LevStr = levStr;
        }

        /// <summary>
        /// 解析类属性
        /// </summary>
        /// <param name="t"></param>
        /// <returns></returns>
        public static AccessLevAttribute ParseClass(Type t)
        {
            return Parse(t.GetCustomAttributes(attrType, false));
        }

        /// <summary>
        /// 解析方法属性
        /// </summary>
        /// <param name="m"></param>
        /// <returns></returns>
        public static AccessLevAttribute ParseMethod(MethodInfo m)
        {
            return Parse(m.GetCustomAttributes(attrType, false));
        }

        static AccessLevAttribute Parse(object[] attributes)
        {
            return (attributes == null || attributes.Length != 1) ? null : attributes[0] as AccessLevAttribute;
        }
    }

页面基类:

public class PageBase : System.Web.UI.Page
    {
        public PageBase()
        {
            this.Init += new EventHandler(PageBase_Init);
        }

        void PageBase_Init(object sender, EventArgs e)
        {
            Type clssType = this.GetType().BaseType;

            var classAttr = AccessLevAttribute.ParseClass(clssType); //获取类上定义的权限数据
            Response.Write(classAttr == null ? clssType.Name : classAttr.Name);

            foreach (var m in clssType.GetMethods(BindingFlags.DeclaredOnly | BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic))
            {
                var a = AccessLevAttribute.ParseMethod(m); //获取方法上定义的权限数据
                Response.Write(a == null ? m.Name : a.Name);
            }

        }
    }

页面类:

[AccessLev("classAliasName")]
    public partial class WebForm1 :PageBase
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }

        [AccessLev("methodAliasName")]
        string Test()
        {
            return DateTime.Now.ToString();
        }
    }

验证在基类中统一完成,相对一般的基于url验证更安全,且可细化到页面的方法级

时间: 2024-11-06 23:22:04

基于页面的权限设计原形的相关文章

基于角色的权限设计(一)

在任何系统中,权限设计是最基础的东西,本文给出一个基于角色的权限设计的循序渐进的设计方案. 在权限系统中,功能(权限)是最小的单位,比如起草新闻.编辑新闻.审核新闻.删除新闻等,而角色是一类功能的集合,比如新闻编辑 这个角色,他可能有起草新闻.编辑新闻等功能集合,而责任编辑他可能就有更多的权限,比如除了新闻编辑的功能,还有审核新闻.删除新闻等功能,给张三赋予 新闻编辑的角色(其实我更愿意说把张三加入到新闻编辑这个角色中去),张三就可以起草新闻.编辑新闻了,给李四赋予责任编辑的角色,李四就可以起草

基于角色的权限设计(二)

第一部分请參看:http://blog.csdn.net/snomyc520/article/details/38677861 针对这种需求,版本号一就无能为力了(当然你也能够添加几个功能:比方分类A的新闻起草和分类B的新闻起草,再把这个功能加入到对应的角色里面去,可是这个应该不是我们要得解决方式吧,只是版本号二也是基于这个思想来解决的). 事实上比新闻更好的样例是论坛板块的版主. 以下是版本号二的解决方式: 在版本号二的功能表中增加了一个ResourceType这个字段,这个字段用来表示对某个

Node——前端权限设计与后端权限设计

前端权限设计 前端利用 vue 框架实现权限设计 在 store 中存储用户信息 userInfo,其中包含用户权限等级信息 用户发起请求到 nginx 服务器中拿到页面,此时会根据 store 中的信息判断是否渲染此组件 用户暴力操作,例如直接输入用户没有权限访问的地址怎么办? 后台也会进行判断,对用户进行拦截,并统一回复没有权限的标识,标识可以自定义,例如 code:403 前端接收到后台发送的信息,需要注意的是每次接收都是封装过的,都进行了拦截配置,当拦截到没有权限的标识会立刻跳转到路由到

net core体系-web应用程序-4asp.net core2.0 项目实战(1)-13基于OnActionExecuting全局过滤器,页面操作权限过滤控制到按钮级

1.权限管理 权限管理的基本定义:百度百科. 基于<Asp.Net Core 2.0 项目实战(10) 基于cookie登录授权认证并实现前台会员.后台管理员同时登录>我们做过了登录认证,登录是权限的最基础的认证,没有登录就没有接下来的各种操作权限管理,以及数据权限管理(暂不探讨),这里我们把登录当作全局权限,进入系统后再根据不同的角色或者人员,固定基本功能的展示,当不同的角色要对功能操作时,就需要验证操作权限,如:查看/添加/修改/删除,也就是我们常说的控制到按钮级.下面让我们一步一步来操作

多租户通用权限设计(基于casbin)

多租户通用权限设计(基于 casbin) 所谓权限控制, 概念并不复杂, 就是确认某个操作是否能做, 本质上仅仅就是个bool判断. 权限几乎是每个系统必不可少的功能, 和具体业务结合之后, 在系统中往往表现的非常复杂和难于控制, 很大部分原因是把权限和具体业务结合的太过紧密, 把业务的复杂度也加入到权限控制中来了. 一直以来, 都有个想法, 想做一套简单好用的通用权限系统, 和任何业务都没有关系, 仅仅就是权限本身的功能. 对此, 做过很多尝试, 由于设计能力有限, 最后都不了了之, 没能坚持

一个基于RBAC0的通用权限设计清单

注:RBAC0与RBAC1不同在于权限继承.关于RBAC1的权限设计,敬请关注作者后续CSDN博客.1,用户表 保存系统用户信息,如张三.李四,字段可以有id.name.fullname.email.phone.……2,角色表 保存角色信息,如学生.管理员,字段有id.name.……3,权限表 保存系统的权限信息,可定义系统哪些模块公开,或者什么时段可访问,字段有id,权限名4,用户角色表 关联用户和角色的关系表,如张三-学生,李四-管理员,字段有id.用户id.角色id,根据用户就知道所属的角

OFBiz 初步 之 权限设计

简介 Apache Open For Business(Apache OFBiz) 是Apache开源的一个经典ERP项目.它提供了一套企业应用,用于集成以及自动化一些企业的"商业流程". 从学习角度来看,它也是一个非常不错的企业级应用框架.这篇文章从OFBiz的权限设计这一切入点来谈谈OFBiz对于应用系统的权限设计. 设计思想简述 OFBiz采用的"安全组"(Security Group)来将"权限"跟"用户"联系起来.系

RBAC用户角色权限设计

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接将

百万年薪python之路 -- RBAC角色权限设计

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型. 在这种模型中,用户与角色之间,角色与权限之间,一般都是多对多的关系. 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,"超级管理员"."版主"都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权