权限设计模型（MVC怎么设置权限）

本文目录

• MVC怎么设置权限
• WORD权限设置(RMS) 中怎么设置20多种自定义策略并怎么应用
• 知识管理系统的权限模型以“个人为中心”还是以“组织架构”为中心
• 如何设计一个权限框架
• 帮忙设计个有关权限，角色，用户，日志的表或数据模型
• 基于RESTful API 怎么设计用户权限控制

MVC怎么设置权限

MVC模式是“Model-View-Controller“的缩写，中文翻译为“模式-视图-控制器“。MVC应用程序总是由这三个部分组成。Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。类似的，只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己。MVC模式最早是smalltalk语言研究团提出的，应用于用户交互应用程序中。smalltalk语言和java语言有很多相似性,都是面向对象语言，很自然的SUN在petstore(宠物店)事例应用程序中就推荐MVC模式作为开发Web应用的架构模式。MVC模式是一种架构模式，其实需要其他模式协作完成。在J2EE模式目录中，通常采用service to worker模式实现，而service to worker模式可由集中控制器模式，派遣器模式和Page Helper模式组成。而Struts只实现了MVC的View和Controller两个部分，Model部分需要开发者自己来实现，Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。 MVC模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经终结出了很多可靠的设计模式，多种设计模式结合在一起，使MVC模式的实现变得相对简单易行。Views可以看作一棵树，显然可以用Composite Pattern来实现。Views和Models之间的关系可以用Observer Pattern体现。Controller控制Views的显示，可以用Strategy Pattern实现。Model通常是一个调停者，可采用Mediator Pattern来实现。 现在让我们来了解一下MVC三个部分在J2EE架构中处于什么位置，这样有助于我们理解MVC模式的实现。MVC与J2EE架构的对应关系是:View处于Web Tier或者说是Client Tier，通常是JSP/Servlet，即页面显示部分。Controller也处于Web Tier，通常用Servlet来实现，即页面显示的逻辑部分实现。Model处于Middle Tier，通常用服务端的javaBean或者EJB实现，即业务逻辑部分的实现。一、MVC设计思想 MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。 视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。 模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。 业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。 控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。 二、MVC设计模式的实现 ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来说有明显的优点。将用户显示（视图）从动作（控制器）中分离出来,提高了代码的重用性。将数据（模型）从对其操作的动作（控制器）分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决耦合系统问题的方法。 2.1 视图 视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面可以展示来自多个数据源的内容，并且网页人员，美工能独自参与这些Web页面的开发和维护。 在ASP.NET下，视图的实现很简单。可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即：一个页面由多个子视图(用户部件)组成；子视图可以是最简单HTML 控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动创建页面。针对静态的模板内容，如页面上的站点导航，菜单，友好链接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，由于用户的请求不同，只能使用后期绑定，并且针对用户的不同，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它增强了可重用性，并原型化了站点的布局。 视图部分大致处理流程如下：首先，页面模板定义了页面的布局；页面配置文件定义视图标签的具体内容（用户部件）；然后，由页面布局策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的校验，用户部件把数据自动提交给业务实体即模型。 这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：置文件有模板配置、页面配置、路径配置、验证配置等。 2.2 控制器 为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。 用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理所有请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。 为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET 提供低级别的请求/响应 API，使开发人员能够使用 .NET 框架类为传入的 HTTP 请求提供服务。为此，必须创作支持 System.Web.IHTTPHandler 接口和实现 ProcessRequest() 方法的类即：请求捕获者类，并在web.config 的 ＜

WORD权限设置(RMS) 中怎么设置20多种自定义策略并怎么应用

我想你应该说的是文档保护了...也就是Microsoft Windows Rights Management Services (RMS) Microsoft Office 2003 中的信息权限管理本页主题：主要概念和定义信息权限管理概述IRM的优点在Office 2003中使用IRM部署概述结论常见问题查找更多信息发布日期：2003年7月21日摘要：信息权限管理（Information Rights Management，IRM）是一项持续存在的文件级技术，旨在保护文档和电子邮件信息免受未经授权的访问。IRM将Windows Rights Management Services（权限管理服务）的范围延伸到了Microsoft Office 2003 应用程序和Microsoft Internet Explorer之中。本白皮书概要介绍了信息权限管理的优点、实现方式以及部署时应该考虑的注意事项。主要概念和定义Windows权限管理（Windows Rights Management） － Windows中的一个可扩展的信息保护组件，用来保护敏感信息的安全。Windows权限管理服务（Windows Rights Management Services，RMS） - Windows Server 2003的一个功能，RMS是Windows权限管理平台的服务器组件。信息权限管理（Information Rights Management）－ IRM是Windows权限管理服务（RMS）在Office 2003 应用程序和Internet Explorer中的扩展（通过一个免费的加载项）。无论是在组织机构内部还是通过一个Microsoft服务实现，Office 2003中的IRM均依赖于RMS。信息权限管理概述Microsoft Office 2003中的信息权限管理（Information Rights Management，IRM）为组织和信息工作者控制他们自己的信息提供了又一种有益机制。IRM是Microsoft开发的一种持久性的文件级保护技术，它允许信息工作者对有权访问和使用文档或电子邮件的人员加以指定，并且能够保护信息不受未经授权的打印、转发或复制。IRM对一种被称作Windows 权限管理（Windows Rights Management）的关键Windows 平台技术进行了扩展。权限管理是Windows 的一种信息保护特性，它可以与应用程序相配合，对机密和敏感的企业信息加以保护--无论这些信息被发送到什么地方。作为对用户所提出的改善内容保护要求的响应，Microsoft将权限管理设计为一个可扩展的平台，可以集成到Office 2003以及各种第三方应用程序之中。IRM是一个策略工具，在对有权使用文档的人员和文档的使用目的进行控制的同时，允许用户对文档进行共享和通过电子邮件发送文档。因为IRM保护随着文件移动，所以该技术可以保护文档或者电子邮件，无论这些信息移动到什么地方，访问限制始终附加在信息之上；即便是文件被发送到了防火墙的外部也是如此。但是，IRM并不是一个安全特性。在用户被授予了有限制的权限之后，应用程序UI和对象模型还会应用剩余的其它限制。和其它策略工具一样，这些限制不能防止任何形式的滥用现象发生。 有两种方法能够启用Office 2003中的IRM功能。对于本身没有运行Windows权限管理服务的家庭用户或组织机构来说，Microsoft已经提供了一个服务。通过结合使用Passport身份验证和该服务，这些用户可以利用关键IRM特性保护他们的敏感信息的安全。另一种方法要求在组织的计算基础结构中配置RMS，以便实现Office 2003所包含的所有IRM功能。为了全面讨论信息权限管理技术拥有的潜力，本白皮书假定组织在企业内部使用RMS。在介绍了IRM的一些关键优点之后，本文将继续探究IRM在Office 2003应用程序内的某些特定使用情境，以及IRM的基本体系架构和IRM的部署方式。IRM的优点Office 2003对IRM的支持可以帮助企业和信息工作者解决以下基本需要：· 信息的私密性、控制能力和完整性 － 信息工作者经常需要处理机密或者敏感的信息内容，并且根据对其它人的判断保证敏感信息不被泄漏。通过禁用受IRM保护的文档和电子邮件中的相应功能，IRM可以帮助用户控制信息不受未经授权的操作，例如转发、粘贴或者打印等。对于IT管理人员，IRM能够根据文档的机密性应用现有的企业策略。对于CEO和安全官员，它能够降低关键的企业信息落入别有用心的人手中所带来的风险，无论是在发生事故、失误或者受到恶意侵犯的情况下。 在组织启用了IRM的情况下，Office 2003的用户可以轻松利用该技术。IRM提供了一个完全集成在Office 2003应用程序中的简单的用户界面。与Active Directory 服务的集成提供的便利则是目前基于口令的文档保护所无法比拟的。最后，免费的Internet Explorer权限管理加载项使得无论是否拥有Office 2003的用户均可以查看受IRM保护的文档，从而允许组织在那些目前尚没有升级到最新版本的Office程序的员工之间共享机密信息。使用Office 2003中的IRMOffice 2003中的IRM依赖Windows权限管理服务为其提供核心功能。虽然如此，IRM仍然与Office 2003完全集成，并且作为一个简单和自然的扩展加入在用户早已熟悉的内容创建和协作过程之中。使用IRMIRM保护的设计不仅易于使用，而且对于最终用户是透明的。使用IRM的过程由三个基本步骤组成：·应用IRM － 作者在Office 2003程序中创建内容时，点击“权限“菜单按钮，然后指定需要授予的权限，例如按照用户或组授予的访问级别，是否允许用户打印等等。·分发 － 作者可以分发文件，将数据附加到电子邮件中，将文件张贴到共享文件夹，或者通过磁盘分发这些文件。IRM保护是文件级别的保护，所以信息工作者不需要改变他们现在所使用的各种信息共享方式。·使用 － 收件人可以如同以前一样打开文档或文件。而在打开文件这一过程的背后，程序需要和RMS服务器进行通信以确定用户是否拥有访问文件所需的权限。RMS对用户及其发出的请求进行验证，然后发放一个用户许可证。然后，应用程序打开文件并且应用权限限制。 Outlook 2003电子邮件中的IRMIRM可以用在Microsoft Office Outlook 2003中，以防止电子邮件被转发、复制或打印。受保护的邮件在发送之前自动进行加密处理，在接收邮件时，Outlook 2003便对邮件应用权限限制。附加在受保护邮件中的Office 2003文档也会自动得到保护。Excel 2003和Word 2003文档中的IRM如上所述，Office 2003文档可以按照用户或者按照组加以保护（基于组的权限要求Active Directory针对组进行了扩展）。所有用户或组都可以根据文档拥有者所定义的访问级别赋予一组权限：读、修改或者完全控制。根据访问级别的不同，IRM会禁用相关的命令以应用所分派的权限设置。拥有者还可以防止文档被打印，并且设置文档的过期日期。在过期之后，文档将不能被打开。如果一个受保护的文档被转发到一个未经授权的收件人处，会显示一条带有文档拥有者电子邮件地址的错误信息，以方便用户向拥有者索取相应权限。如果文档的拥有者决定不在文档中包括自己的电子邮件地址，未经授权的收件人将获得一个通知，告知他没有查看或访问该文件的权限。自定义许可权限策略利用IRM 技术，Office 2003允许企业创建权限策略，这些策略出现在Office 2003应用程序之中。例如，某个公司可能定义了一个名为“公司机密“的模板，该模板指定受模板保护的文档或电子邮件只能被公司域内部的用户所打开。能够创建的策略数量没有任何限制。针对Internet Explorer的权限管理加载项 因为权限的应用在应用程序级别完成，为了创建带有IRM的Word、Excel或PowerPoint文件，或者使用Outlook发送带有IRM的邮件，Office 2003都是必需的。对于受保护电子邮件或者HTML内容的阅读，Microsoft为那些没有Office 2003的用户提供了一个免费的Internet Explorer加载项软件。在通过Word、Excel或PowerPoint使用IRM时，作者可以选择将文档的HTML表述包括进来，以便能够利用该加载项阅读。作者所定义的权限将被应用在HTML表述上，就如何应用在Office应用程序上一样。加载项可以免费从以下地址下载：（用户可能需要支付连接费用）。该加载项还在企业与合作伙伴的沟通过程之中扮演了一个重要的角色，因为用户可以自由选择在何时迁移到Office 2003。借助于该加载项产品，那些希望利用IRM创建受保护内容的公司可以转移到Office 2003平台上，而且他们知道即便用户没有Office 2003，也依然可以访问公司创建的文档。部署概述 以下内容介绍了在部署IRM时应当注意的关键事项，例如基础结构需求。IRM组件位于IRM核心的Windows权限管理技术构建在 .NET Framework、ASP.NET和可扩展权限标记语言（Extensible Rights Markup Language，XrML）的基础之上，XrML是一种新兴的基于XML的权限表述语言标准。XrML为数字内容和服务的权限及策略的表述提供了一条通用和易于使用的途径。以下项目是在Office中实现IRM所必需的：·运行在Windows Server 2003 之上的Windows权限管理服务（RMS）·面向Windows 客户端的权限管理升级·Office 2003 部署IRM以下是与上述三个要求相对应的IRM部署步骤：1. 服务器登记 － 首先，IT管理人员必须“激活“RMS服务器。2. 安装Office 2003 客户端 － 接下来，IT管理员需要在客户端计算机上安装针对Windows 客户端的权限管理升级文件。3. 客户端计算机激活 － 在客户端计算机安装完毕之后，所有的计算机都必须连接到企业的RMS服务器上激活计算机。以便计算机能够发布和使用受保护的内容。本过程必须由拥有管理特权的人员或程序完成。4. 用户登记 － 在计算机激活之后，所有的用户都必须经过RMS服务器的身份验证，以获得用来加解密文件内容的凭据（RAC） Microsoft IRM 服务Microsoft 还将为那些本身不运行Windows 权限管理服务的用户提供一个IRM服务。该服务允许用户使用Microsoft Passport而不是使用Active Directory作为共享受保护文档和电子邮件的身份验证机制。请注意：该服务的用户无法创建定制的权限模板，例如前面提到过的“公司机密“模板。总结本白皮书介绍了信息权限管理技术，该技术是Windows Server 2003中的Windows 权限管理服务在Office 2003中的具体实现。但他不支持打印保护等一些高级功能,最近成都微软技术中心推出了一款你所文档保护系统,功能之强大,但必须运行与AD之上...

知识管理系统的权限模型以“个人为中心”还是以“组织架构”为中心

楼主想要讨论的应该是指的企业或组织的知识管理系统吧。在一个知识管理系统中，应该充分考虑到以下几种权限元素。1.人，即知识库的参与者与建设者。2.组织架构，即人所在的部门或机构。3.角色，即人所担任的职务或职能的概称。4.知识，即知识库中的知识内容5.功能，即知识管理系统本身的功能。在成熟的知识管理系统中，知识的最终对象，还是人，因为最终还是由一个具体的人（账号）来使用知识库的具体功能。但是在这个过程中，这个用户最终能够使用到的权限体系却不能仅仅针对人来设置。因为，一旦知识库用户成千上万时，一个用户一个用户的来设置权限，是一件非常恐怖的事情。基于此，kmpro知识管理系统的权限体系设置认为，知识库中一个用户的权限取决于以下公式：用户（人）的权限=（角色+组织+人的特例权限）*（知识权限+功能权限）解释一下，一个用户的权限集，取决于这个用户的角色所拥有的权限，加上该用户所在组织机构的通用权限，加上系统赋予该用户的特例或临时权限。人、角色、组织的权限类别分为两套，一套是针对知识能有什么权限，比如阅读、修改、删除、审核等，另一套是针对系统有什么权限，比如能否使用公告，修改个人资料等与知识无关的功能权限。--------------------参考kmpro知识管理系统的权限设置对任何一个系统而言，权限体系是必不可少的组成部分，对知识管理系统而言，权限体系意味着“正确的人，在正确的地方，获取正确的知识”，也意味着知识的安全，不同的角色在不同的知识分类，对不同的知识内容应该拥有不同的权限。而权限的细分应该是细粒度的，包括增删改查、下载打印点评等等用户的行为都应在可控范围之内。因此，本项目的权限管理应满足以下需求： 字串1Ø 可以定制角色、岗位（用户组），与用户是多对多的关系，即一个角色或岗位可授予多个用户，一个用户可拥有多个角色和岗位。 字串3 Ø 提供灵活的权限控制，可以设置单个用户对任何对象的单项操作的权限、对任何属性的访问权限。 字串7 Ø 根据权限向用户提供可操作的范围，例如，设置某用户的权限只能在“综合征管软件”类别下增加知识，那么该用户在增加知识时，系统只显示出“综合征管软件”类别及其子类别供用户选择知识的归属。 字串2Ø 权限粒度划分细致，对知识和知识分类的权限控制较为细致，支持增加、删除、修改、拷贝、下载、打印、点评、复制等细粒度的权限设置。 字串4Ø 可以批量设置权限。 字串1 Ø 匿名用户可以浏览和搜索知识，管理人员可以通过权限设置随时取消该或恢复该权限。 字串9Ø 支持用户注册，默认拥有普通用户的权限，可浏览、搜索、评论、贡献知识等。 字串2Ø 提供高级的用户管理功能，例如锁定用户名、封IP等。 字串4

如何设计一个权限框架

权限可以简单理解为某个操作的是否可以进行，其中权限的框架设计至关重要。方法/步骤第一步：设计主体部分进行身份认证。第二步：进行身份认证后，给出认证的凭证。第三步：进行筛选，执行通过的操作，然后进行相应的授权。第四步：通过判定有权限则执行、没有权限就不能执行。

帮忙设计个有关权限，角色，用户，日志的表或数据模型

权限 我原来设计过一个 用的是四张表userinfo-----》roleinfo roleid rolename userid | username | roleid Vrightinfo---》rolerightinfo rightid rolerightid parentid roleidrightname rightid我把设计大概的图给你弄出来了 你自己看看

基于RESTful API 怎么设计用户权限控制

本文是基于RESTful描述的，需要你对这个有初步的了解。RESTful是什么？Representational State Transfer，简称REST，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。REST比较重要的点是资源和状态转换，所谓“资源“，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。而“状态转换“，则是把对应的HTTP协议里面，四个表示操作方式的动词分别对应四种基本操作：1. GET，用来浏览(browse)资源2. POST，用来新建(create)资源 3. PUT，用来更新(update)资源4. DELETE，用来删除(delete)资源。资源的分类及操作清楚了资源的概念，然后再来对资源进行一下分类，我把资源分为下面三类：1. 私人资源 (Personal Source)2. 角色资源 (Roles Source)3. 公共资源 (Public Source)“私人资源“：是属于某一个用户所有的资源，只有用户本人才能操作，其他用户不能操作。例如用户的个人信息、订单、收货地址等等。“角色资源“：与私人资源不同，角色资源范畴更大，一个角色可以对应多个人，也就是一群人。如果给某角色分配了权限，那么只有身为该角色的用户才能拥有这些权限。例如系统资源只能够管理员操作，一般用户不能操作。“公共资源“：所有人无论角色都能够访问并操作的资源。而对资源的操作，无非就是分为四种：1. 浏览 (browse)2. 新增 (create)3. 更新 (update)4. 删除 (delete)角色、用户、权限之间的关系角色和用户的概念，自不用多说，大家都懂，但是权限的概念需要提一提。“权限“，就是资源与操作的一套组合，例如“增加用户“是一种权限，“删除用户“是一种权限，所以对于一种资源所对应的权限有且只有四种。角色与用户的关系：一个角色对应一群用户，一个用户也可以扮演多个角色，所以它们是多对多的关系。角色与权限的关系：一个角色拥有一堆权限，一个权限却只能属于一个角色，所以它们是一(角色)对多(权限)的关系权限与用户的关系：由于一个用户可以扮演多个角色，一个角色拥有多个权限，所以用户与权限是间接的多对多关系。需要注意两种特别情况：1. 私人资源与用户的关系，一种私人资源对应的四种权限只能属于一个用户，所以这种情况下，用户和权限是一(用户)对多(权限)的关系。2. 超级管理员的角色，这个角色是神一般的存在，能无视一切阻碍，对所有资源拥有绝对权限，甭管你是私人资源还是角色资源。数据库表的设计角色、用户、权限的模型应该怎么样设计，才能满足它们之间的关系？对上图的一些关键字段进行说明：Sourcename: 资源的名称，也就是其他模型的名称，例如：user、role等等。identity: 资源的唯一标识，可以像uuid，shortid这些字符串，也可以是model的名称。permissions : 一种资源对应有四种权限，分别对这种资源的browse、create、update、deletePermissionsource : 该权限对应的资源，也就是Source的某一条记录的唯一标识action ：对应资源的操作，只能是browse、create、update、delete四个之一relation：用来标记该权限是属于私人的，还是角色的，用于OwnerPolicy检测roles: 拥有该权限的角色Roleusers : 角色所对应的用户群，一个角色可以对应多个用户permissions: 权限列表，一个角色拥有多项权利UsercreateBy : 该记录的拥有者，在user标里，一般等于该记录的唯一标识，这一属性用于OwnerPolicy的检测，其他私有资源的模型设计，也需要加上这一字段来标识资源的拥有者。roles : 用户所拥有的角色策略/过滤器在sails下称为策略(Policy)，在java SSH下称为过滤器(Filter)，无论名称如何，他们工作原理是大同小异的，主要是在一条HTTP请求访问一个Controller下的action之前进行检测。所以在这一层，我们可以自定义一些策略/过滤器来实现权限控制。为行文方便，下面姑且允许我使用策略这一词。*策略 (Policy) *下面排版顺序对应Policy的运行顺序SessionAuthPolicy：检测用户是否已经登录，用户登录是进行下面检测的前提。SourcePolicy：检测访问的资源是否存在，主要检测Source表的记录PermissionPolicy：检测该用户所属的角色，是否有对所访问资源进行对应操作的权限。OwnerPolicy：如果所访问的资源属于私人资源，则检测当前用户是否该资源的拥有者。如果通过所有policy的检测，则把请求转发到目标action。