转:http://blog.csdn.net/yl_99/article/details/7767053

1.MOSS中的权限结构

MOSS中的权限结构主要有三部分:网站权限,列表权限,个人权限。

网站权限由18种如下图:

clip_image002

列表权限由12种,如下图:

clip_image002[5]

个人权限由三种,如下图:

clip_image002[7]

2.权限级别

上面提供的就是基本的权限,不同的权限组成MOSS中的权限级别。MOSS本身为我们提供了一些权限级别,我们也可以根据自己的需求来自定义。

我们在自定义自己的权限级别的时候可以参考Moss本身的,在他的基础上进行修改,我们编辑现有的网站级别,里面提供了一个复制权限级别的功能,
我们可以复制一份在这个基础进行修改来定义我们自己的权限级别。

clip_image002[9]

3.下图展示了MOSS权限,用户和权限对象之间的关系:

clip_image002[11]

4.使用SharePoint对象模型控制权限

主要使用下面几个类:

SPUser,SPGroup,SPRoleDefinition,SPRoleAssignment。

SPRoleDefinition用于角色(即前面所说的“权限级别”)的定义

它的几个重要的属性有:

Name:角色名称
Description:角色描述
BasePermissions:角色的权限(就是在这个地方指定详细的权限)
另外,Type属性是SPRoleType枚举类型的,关于权限的枚举是SPBasePermissions

SPRoleAssignment用于权限的分配,它比较简单,只有三个public的属性:

Member:把权限分配给谁
Parent:在什么东西上分配权限
RoleDefinitionBindings:分配什么权限

Member是SPPrincipal类型的是SPUser和SPGroup的父类
Parent:实现了ISecurityxxxx接口
RoleDefinitionBindings:可以理解为SPRoleDefinition的一个集合

在2007里面每一个能分配权限的东西(SPWeb、SPList、SPListItem等)都会有一个RoleAssignments属性,它是一个SPRoleAssignmentCollection类型的属性,
用于分配权限

此外,在SPWeb里还有RoleDefinitions属性(只在SPWeb里有,也就是说角色只能定义在网站里)

举例如下:

我们要给一个用户(user)分配一个在列表(list)上的权限,权限使用了一个名叫“xxx”的角色

代码如下:

SPRoleAssignment ra = new SPRoleAssignment(user);

SPRoleDefinition rd = web.RoleDefinitions["xxx"];

ra.RoldDefinitionBindings.Add(rd);

list.RoleAssignments.Add(ra);

又比如,修改一个用户的权限:

SPRoleAssignment ra = list.RoleAssignments.GetAssignmentByPrincipal(user);

SPRoleDefinition rd = web.RoleDefinitions["xxx"];

ra.RoldDefinitionBindings.Add(rd);

ra.Update();但是,如果这个列表的权限之前是继承自网站的,

那么上面的代码并不会自动的修改这种继承,反而会抛出异常

我们必须手工解除这种继承关系:

list.BreakRoleInheritance(true);

参数中true的意思是把继承下来的权限重新copy过来(如果你不改它的话,它和网站的权限还是一样的),如果是false,则使用列表模版中定义的默认权限

如果要新建一个角色的话,直接new一个SPRoleDefinition,改改它的Name、Description、BasePermissions属性,然后再加到web.RoleDefinitions里就可以了;
或者在new的时候可以选择一个现有的角色copy过来,再改一改。这个代码我就不写了

此外,在权限方面还有一些其他的小改动:

在2003里,使用xxx.Permissions得到xxx(可以是SPWeb、SPList)的权限,但是在2007里Permissions属性也被废弃了

我们记得Permissions有一个非常有用的东西叫DoesUserHavePermissions来判断当前用户权限的,

在Permissions属性被废弃掉之后,这个方法移植到了SPWeb、SPList等类里

直接使用list.DoesUserHavePermissions就ok了

而且,现在这个方法不仅可以判断当前用户的权限,也可以判断指定用户的权限(通过SPUser)

另外,SPWeb、SPList及SPListItem也加入了CheckPermissions方法来判断用户权限,如果没有则丢一个异常出来,这和以前的xxx.Permissions.Demand方法是一致的

5.角色定义,分配,继承

角色由两部分组成:角色定义和角色分配。

角色定义,或者说权限级别,是与角色关联的权限列表。权限是 SharePoint 网站中唯一可控制的操作。例如,具有 Read 角色的用户可以浏览网站中的页面并查看列表中的项目。与 Windows SharePoint Services 2.0 中不同,在 Windows SharePoint Services 3.0 中,从不直接使用权限来管理用户权限。所有用户权限和组权限都通过角色来管理。角色定义是与特定对象绑定的权限集合。角色定义界定于网站范围内(例如,Full ControlReadContributeDesignLimited Access),并且在网站内的各个位置具有相同的意义,但其在同一个网站集内各网站之间的可能有所不同。角色定义也可以从父网站继承,就像权限一样。

角色分配是角色定义、用户和组以及范围之间的关系(例如,一个用户可能是列表 1 上的读者,而另一个用户是列表 2 上的读者)。通过角色分配表示的关系是使 Windows SharePoint Services 安全管理基于角色的关键。所有权限都通过角色来管理;您从不向用户直接分配权限,而只分配定义完善、一致、含义丰富的权限集合(角色定义)。通过角色分配向角色定义中添加或从中移除用户和组,以此来管理独有权限。

网站管理员可以使用“管理角色”页来自定义默认角色定义和创建其他自定义角色,其中,“管理角色”页列出了网站中可用的角色定义。

角色定义继承

Windows SharePoint Services 支持继承角色定义,就像它支持继承权限那样,而取消角色定义继承也要求取消权限继承。

每个 SharePoint 对象都可以拥有自己的权限集,也可以从其父容器继承权限。Windows SharePoint Services 不支持部分继承,对象将继承其父级的所有权限,并且也可以拥有一些自己的权限。权限可以是独有的,也可以是继承的。Windows SharePoint Services 不支持定向继承。例如,对象只能从其父容器继承,而不能从某些其他对象或容器继承。

当网站继承角色定义时,这些角色是只读的,就像继承的网站中的只读权限一样。用户将获得导航到拥有独有角色定义的父网站的链接。所有新网站(包括拥有独有权限的新网站)的默认设置都是从父网站继承角色定义。如果是独有权限,则角色定义可以还原为继承的角色定义,或编辑为本地角色定义。

根据下列禁止规则,网站中的角色定义继承对权限继承产生影响:

· 不能继承权限,除非它还继承角色定义。

· 不能创建独有角色定义,除非它还创建独有权限。

· 不能还原为继承的角色定义,除非它也还原网站中的所有独有权限。现有权限依赖角色定义。

· 不能还原为继承的权限,除非它也还原为继承的角色定义。网站的权限始终与网站的角色定义关联。

 

权限级别

作为站点所有者,您可以将下列个人权限级别分配给 SharePoint Online 用户:

  • 完全控制:用户具有完全控制权限,可以在站点上更改内容、调整站点设置以及管理权限。
  • 设计:用户可以查看、添加、更新、删除、批准和自定义站点及其内容。
  • 参与:用户可以查看和更改内容,但是无法更改站点本身。
  • 读取:用户可以查看站点及其内容,但无法进行任何更改。
  • 受限访问:授予权限后,用户可以查看特定列表、列表项、文档库、文件夹或文档。

权限可保护机密信息并防止对您的站点内容进行未授权的更改。它们还可阻止未授权的用户更改站点结构。

管理权限

默认情况下,站点上的权限只能由具有完全控制权限或管理员权限的用户更改。

可以通过创建具有特定权限级别的组,然后将用户分配给该组,来分配权限。SharePoint Online 提供了一系列默认组,其中分配了不同的用户权限。

  • “访问者”组具有“读取”权限。
  • “成员”组具有“参与”权限。
  • “所有者”具有“完全控制”权限。

站点所有者可以创建具有自定义访问级别的自定义组,并为站点用户添加或更改权限级别。

 

posted on 2014-02-27 17:54  jackljf  阅读(345)  评论(0编辑  收藏  举报