易栈网-膘叔

这还是比较值得推荐的。。。(备注：加载的时候可能有点慢。如果发现加载失败，请重新刷新页面一次)

其实真的不想提这个话题，关于这个话题真的是辛酸泪一把。但总得介绍一下吧。

角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。
Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给 User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。 例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。

基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

RBAC基本概念：

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）

What：权限针对的对象或资源（Resource、Class）。

How：具体的权限（Privilege,正向授权与负向授权）。

Operator：操作。表明对What的How操作。也就是Privilege+Resource

Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.

Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。

RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。

凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。

Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所 有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session.

在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念 就具象到一个人。

这里的Group和GBAC（Group-Based Access Control）中的Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。

Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。

Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的 Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机 构。例如，可以有副经理这个Group，这是多人有相同职责。

引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。

Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给 User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。 例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。

基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

本文也是我摘抄来的，原文地址为：http://xinsync.xju.edu.cn/index.php/archives/3693，主要还是想把这个角色权限说明白一些。如果有幸是同事们看到，那真是一大幸事，那些自认为是精英的同事们，你们懂吗？哦，不好意思，又揭你们的短了。

一直以来,IBM developworks都是我比较关注的网站，它上面有很多内容是IBM公司内部人员所写，也有一部分内容是业界领先人士根据自身经验写出的教程，因此，它一直是我的订阅对象之一。本文就是其中一篇比较旧的文章，最初发表于2007年3月15日，但是从今天的眼光来看，它还是有一定的学习价值，所以我贴出来了。

简介如下：（原文我就不贴了，大家可以点其中的链接我自己也会点过去看的）

现在，Web 站点已经成了业务的重要部分，而用来创建和部署 Web 站点的工具也变得更加灵活和容易使用。但是，复杂 Web 应用程序的开发并不轻松，它们需要的不只是标准的交互和更新方法（比如 blog）。组织中的每个应用程序常常还需要进行定制。

开放源码社区提供了各种工具，结合使用这些工具可以为复杂的 Web 应用程序创建一个有用的开发和生产环境。这个系列文章来自 IBM Internet Technology Group 团队，他们将展示如何把开放源码软件作为基础，并提供一种方法和一些改进来帮助简化 Web 站点的开发过程。尽管定制仍然是有必要的，但是这个系列讲解了如何使用开放源码工具和技术快速建立和运行复杂的 Web 站点。

在这个系列中，Internet Technology Group 团队通过一个虚构的组织，International Business Council（IBC），来展示如何更有效地尽可能地扩展 Web 站点的功能，这些功能包括文档存储、讨论组、专门的工作组、研讨会日程安排、日程议题描述、会话过期和其他任务。他们举例说明了创建这个 Web 站点需要用到下列开放源码工具：

• Drupal - 开放源码的内容管理系统
• MySQL - 开放源码的数据库
• PHP - 可以使用 PHPMyAdmin 和 SQLBrowse 创建动态 Web 内容的开发语言
• Apache - 开放源码的 Web 服务器
• Eclipse - 开放源码的开发环境
• CVS - 用于跟踪代码变更的代码管理系统

Internet Technology Group 团队会首先介绍业务场景以及选择开源工具的决定因素，他们还通过描述一个灵活的开发方法来讲解了应用程序的设计流程。这个流程可以用来设计 Web 站点或者应用程序的用户体验。接着，他们会一步一步地指导如何安装和使用前面所提到的开发工具套件。这些步骤包括：

• 建立开发环境
• Drupal 入门
• 着重介绍 Drupal 与其它软件工具的交互（如 MySQL， Ajax 和 PHP）
• 构建 Drupal 定制模块
• 部署和调整安装

沿着这条道路，Internet Technology Group 团队同其他可选方案进行了对比，并讨论了如何通过集成其它软件组件来尽可能地增强这些工具。

现在就链接到 项目实现：

• 第 1 部分，简介和概述
• 第 2 部分，设计有效的用户体验
• 第 3 部分，在 Windows 中建立开发环境
• 第 4 部分，在 Linux 中建立开发环境
• 第 5 部分，Drupal 入门
• 第 6 部分，在 Drupal 中构建定制模块
• 第 7 部分，使用 XHTML 为主题化内容建立结构
• 第 8 部分，使用 CSS 对主题化内容应用样式
• 第 9 部分，理解数据库层
• 第 10 部分，外部网 Web 站点的特性
• 第 11 部分，使用 Drupal 中的分类法
• 第 12 部分，主机托管和部署
• 第 13 部分，Eclipse 中的 PHP 开发
• 第 14 部分，announcement 模块源代码
• 第 15 部分，学到的经验

文章的内容写的不错，所以转载一下。
原文：http://xinsync.xju.edu.cn/index.php/archives/2946
内容如下：

SVN的机制确实是很多人现在所考虑的，一来这样保证了代码的同步，二来也不需要担心开发版和上线版的区别，更重要的是，每次的update你肯定不会有错。

文件上传其实才是一个大头，当你的服务器过多的时候，你如何保证每一台服务器的上传内容同步？如果你同步了，那么这么多的冗余文件是否是一个浪费？如果你不同步，而采用同一个NFS服务器来存储，那么就象文中说的如果NFS宕机了怎么办？给NFS也来一个负载均衡？

总之，当服务器越来越多的时候，你考虑的就不仅仅是代码的问题，而是架构的问题

在制作 网页的时候，不可避免的会用到Cookie，无论是登录也好，保存状态也好，或多或少，你都会在使用Cookie这个小甜饼。

然而甜饼并不是这么好吃的，吃的过多也会有问题的，如果你的网站COOKIE数量过多，或许你的浏览器就直接打不开这个网页（这点好象是和SERVER端有关，apache接受客户端的COOKIE数量和长度也有限制）

对于用户来说，如果没有做限制的话，那么COOKIE过多会导致后一个新的COOKIE会覆盖掉前面的COOKIE。。

那么，究竟应该有多少COOKIE呢？

以下内容来自DBA Notes网站：

Cookie 是个很有趣的话题。根据 RFC 2109 的描述，每个客户端最多保持 300 个 Cookie，针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多，比如 Firefox 是 50 个) ，每个 Cookie 最多 4K，注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了，对于 Cookie 最重要的就是，尽量控制 Cookie 的大小，不要塞入一些无用的信息。

所以，不要把你想知道的用户行为都采用COOKIE来保存，否则造成的后果恐怕是非常大。在一些大型网站，目前对于用户的行为已经开始逐步采用数据库来控制，这样可以记录用户的一些操作，对于用户的行为分析也能够达到的一定的效果，缺点是加大了数据库的压力。而且对于未登录网站的用户来说，他的行为将变得毫无意义

想象：将用户的一些普通行为采用Cookie保存，重要信息记录数据库。比如用户浏览过的网页记入cookie，而用户停留时间最长的网页则考虑记入数据库（当然，对于那种开着网页不关的人就无法对付了，但仍然可以通过客户端的document.scroll的高度来进行判断，再通过ajax提交 ）意义不是特别大。对于一些象购物车之类的，确实可以考虑存入数据库，否则一旦网页误关闭了对于用户的体验可能并不是很好（给用户一个可选项：cookie或者数据库，但好象有点傻）。。。。。。

随便谈谈吧。。