英文原文

Users and Security

来源

zope.slat.org

翻译作者

由 林忠義 認領，翻譯完成

整理

潘俊勇 转换为简体

第六章 : 使用者与安全

所有的网站应用程式都必须考量安全的部分，所谓的管理安全 security 就是说要管制谁来使用你的应用程式，同时要控制哪些事情是可以做的。安全绝对不是一个系统设计完成后还可以附加上去的部分，相反的，安全本身是设计 Zope 应用程式时必须加以考量的重要成分。

这一章你将学到如何建立与管理你的使用者，然后依照你定出的安全策略来控制你的使用者，让他们在策略范围内使用你的应用程式。

安全 Security 简介

安全指的是控制使用者如何使用你的程式，而你还可以维护你的网站。如果你更深入的考量安全问题，你还可以提供更强大的功能给使用者，像是安全地让一大群人来一起维护你的网站。如果你在安全方面有所疏忽，将会很难控管使用者而使管理网站变的非常繁重。因为如此一来，你的网站将蒙受使用者不当使用而造成损害，还无法正确且适当地提供服务给使用者，更别说让其他人一起来管理网站了。

Zope 对于安全的考量是全方位的，让你建构网站应用程式可以方便许多。Zope 使用同一套的安全系统，不管你是管理网站，或是你为一个新的应用程式建立使用者，都会受到这套安全系统管控。所以 Zope 在安全议题上面，并不会区分使用与管理应用程式的差异，而是一视同仁。看起来似乎有点混淆，但事实上这样做让你方便地将 Zope 本身的安全架构延伸到应用程式的需求上面。

登入与登出 Zope

在第二章各位已经在浏览管理页面时输入使用者名称与密码，通过后方能使用管理介面的功能，同时我们也提到一般网页浏览器的运作模式，所以你必须再使用登出功能来离开 Zope，避免留下个人资料于浏览器上。

如果你企图进入与你的权限不符的禁止区域，Zope 会提示你必须用具有足够权限的使用者名称登入，一般来说，读取公开的区域并不需要登入 Zope ，可以直接使用。

证明 Authentication 与授权 Authorization

所谓的安全不过是考量两个主要的议题，证明 authentication 与授权 authorization。所谓的证明 Authentication 就是让别人知道你是谁，授权 authorization 则是决定谁可以做甚么。Zope 提供分离的功能来辨识使用者与控制作甚么。

当你进入一个保护区域 (例如你浏览一些私人网页)， Zope 会跳出登入的要求，同时核对你输入的使用者资料是否符合，这就是证明 authentication 的功能。必须注意的是 Zope 预设只会对保护区提出证明 authenticate 要求，如果你只是浏览公共区域，那 Zope 并不会要求你证明你是谁，而是假设你的身分是一个无名氏 anonymous 让你到处浏览。

提出证明是进入保护区的第一步，接下来 Zope 必须看看你是否有权利使用或阅览保护区的资料，你与保护区域资料之间牵涉到两个中间因素，角色 roles 与权限 permissions。先说你的部分，你证明你是某个使用者，只要是使用者就会对应一个角色，这个角色描述使用者扮演哪一种角色，像是 "作者"，"管理者"，或是 "编辑者"。至于 Zope 的每个物件也都有其权限设定 permissions ，权限规定像是 "阅览", "删除物件", 与 "管理属性" 这些权限。

安全政策就是要让角色 roles 适当地对应到权限 permissions，换句话说，安全政策决定谁可以做甚么。举例来说，一个安全政策可能会给 "管理者" 角色具有 "删除物件" 权限，这样的政策让管理者具有删除物件的权力， Zope 就是根据这角色与权限来允许使用者在保护区使用保护区的资源。

接下来我们将进一步说明证明与授权，同时说明如何有效设定安全政策，一开始你会学会用使用者与 User Folders 来进行证明，接下来你会学到如何用安全政策来控制授权。

证明 Authentication 与管理使用者

Zope 使用者都会定义一个使用者帐户，纪录 Zope 使用者的名称，密码与一些附加的资料，要登入 Zope 前，你必须先有个使用者帐户，接下来让我们看看如何新增与管理使用者的帐户。

在 User Folders 中建立使用者

要建立使用者帐户你必须在 user folders 中才可以建立，在第二章你应该已经加上一个管理的使用者到最上层的 user folder。

现在让我们加入一个新的使用者来帮你管理 Zope ，先到根档案夹，按入名为 acl_users 的 user folder，这个特殊的档案夹内含使用者物件来定义 Zope 的使用者帐户，按下 Add 按钮来建立一个新的使用者。

Figure 6-1 Adding a user to a user folder.

上图 Figure 6-1 让你定义一个使用者，输入给你夥伴的名字如 "michel"，使用者名称的栏位可以包含英文字母，空白或是数字，但是有区分大小写。

选择给你夥伴使用的密码输入到 Password 与 (Confirm) 栏位，必须先设好密码你的夥伴才可以登入修改成自己要用的密码，你可以设成 "change me" 的密码提醒他登入后换掉。

Domains 栏位可以限制从哪个 Internet domains 可以登入使用，这替使用者加上另一个安全限制，例如你希望你的夥伴只有在公司可以登入管理，你就将你公司的 "myjob.com" 加在这一栏位上，你可以用空白来填入多个 domains 。例如你的夥伴在家上班时，会需要你将他的 ISP 的 domains 加上，这时可以填入 "myjob.com myhome.net"。你也可以用 IP 数字加上万用字元取代 domain names ，例如 "209.67.167.*" 会比对让 IP 地址开头是 "209.67.167" 才可登入。

如果你替某个使用者填入 domain 栏位但是让 password 栏位空着时，只要是从这个 domains 来的人都自动变成这个使用者，可以取得这个使用者的权限，举例说你要让内部网路的同事都可以管理不需登入，你可以建立一个使用者，不填他的 password 只填入 "myjob.com" 到 domain 栏位去，并指定角色为 "Manager"。

角色 Roles 选择列表指明使用者的角色，负责管理的使用者应该指定 Manager 角色，上述中你的夥伴就该选为 Manager 角色，另外 Owner 角色不是相当精确，因为使用者都会有某些特定物件，我们将在本章稍后说明拥有关系，同时你会定义出你自己的 Editor 与 Reviewer 角色。

建立好使用者后，你可以在 user folder 中看到一个新的使用者物件。

编辑使用者

只要点选使用者你就可以编辑已经存在的使用者，这个画面和上述新增使用者的画面与功能一样，你的夥伴登入后需要先到这里改密码。

和所有 Zope 管理功能一样，编辑使用者的功能一样受到安全政策的保护，一个使用者只可以更换密码必须有 Manage Users 这个权限，而 managers 角色预设就具有这个权限。

所以预设上，同一个 user folder 下具有 managers 角色的人可以更改别的管理者密码，这也许是你要的，也可能是你所不想要的。稍后我们会讨论如何避免这个潜在的问题。现在假设你需要这样的功能，例如你的密码被别人取得后，你需要其他的管理者帮你修改密码。

一般来说，user folders 和正常的 Zope folders 一样，你可以建立，编辑与删除里面的物件。但是有些限制，你不可以剪贴使用者，而且只能建立 user 物件。

删除使用者先勾选后按下 Delete 按钮即可删除，当然和所有的 Zope 行为一样，发现误删还是可以 undo 回来。

定义一个使用者的位置

Zope 可以有多重的 user folders 在不同的目录下，一个 Zope 使用者并无法使用超过其 user folder 所在位置上游的资源，所以使用者定义在哪个目录下，他的存取权限就只限于该目录。

你必须在根目录下面的 user folder 有使用者帐号才可以使用根目录下的资源，开始预设的登入帐号都是设在根目录下，你当然也可以将使用者定义在其他的档案夹下面。

举例来说有个 user folder 位置为 /BeautySchool?/Hair/acl_users，同时假设其中有一个使用者叫 Ralph Scissorhands ，Ralph 不能使用 /BeautySchool?/Hair 上层的资源，所以 Ralph 只能浏览 BeautySchool?/Hair 下面的内容，不管你设给 Ralph 何种角色，他的使用资源都跨不出去他定义使用者位置的上层。

使用位置限制存取是一种常见的安全政策设计，通常需要将一些共通的物件放在同一个目录下，然后再这个目录下建一个 user folder 来操控这个目录的物件，这里定义的使用者不会影响到别的上层目录。

举例来说你的公司需要着制服上班，而你正在建构公司内部资讯网站，其中当然也要提供制服资讯，你可以建立一个制服的资料夹，在这个夹中可以放一些制服图片与穿着和清洗的资讯。然后你可以在这个制服夹中建立一个 user folder ，建立给裁缝的帐户。当有新的型号发布时候，这个裁缝可以自行更新这个部分而不需劳动网站管理员。除了更新制服夹之外，这个裁缝并无法登入到这个网站的其他区域去动到不该动的东西。

这种常见安全样式称为委派 delegation，这在一般的 Zope 应用程式中十分常见，藉由委派整个网站的不同区域给不同群组管理可以减少网站管理的负担，稍后我们还会检视其他的安全政策的样式。

与其他种类的 User Folders 合作

也许你的使用者已经有一套证明方式，而你不想另外再建一套引起麻烦，这时你需要使用不同种类的 user folders 来完成， Zope 可以支援各种的证明方式，你可以在 Zope 网站 http://www.zope.org/Products/user_management 上找到相关资讯。目前已经有约 19 种不同的 user folders 可供使用，下面介绍一些常见的 user folders 供参考。

LoginManager?

这是一种具有弹性与威力的 user folder，应用这种 user folder 可以让你挂入自己的证明方式，举例来说，你可以使用 LoginManager? 来达成用资料库提供使用者身份证明的目的。 etcUserFolder

这是一种针对标准 Unix 平台设计的 user folder ，你可以藉由 /etc/password 格式的档案来提供使用者身分证明。

LDAPAdapter?

这种 user folder 可以让你从 LDAP server 取得身分证明。

NTUserFolder?

这种是专供与微软 NT 使用者帐号绑在一起的 user floder ，目前只能运作在 Windows NT 或是 Windows 2000 上面运作的 Zope。

有些 user folders 提供不同方式的登入与登出的机制，像是可以用 web forms 的方式，而不使用浏览器的 HTTP authorization 跳出式登入视窗。尽管方式各异，但是所有的 user folders 都用同样的流程运作，也就是在你进入保护区时，先提示你输入身分认证资料，然后核对身分后，你才可以在该区进行的活动。

虽然所有的使用者帐户都放在各种的 user folders 中管理，但是有一些特殊的 Zope 使用者帐户却不会建在 user folder 中，而是另外的地方。

特殊的使用者帐户

Zope 有三种你不会在 user folders 发现的使用者， anonymous user，emergency user 与 initial manager。这个 anonymous user 算是整个 Zope 应用最多的使用者帐户，至于 emergency user 与 initial manager 这两个虽很少用到，却是非常重要。

Zope Anonymous User

这是 Zope 替一般访客内建的使用者，如果你没有使用一个使用者帐户登入之前， Zope 会视你为这个身分，就是 anonymous user。

这个内建的 anonymous user 也和其他的使用者一样具有安全控制的功能，预设的角色是 Anonymous。预设的 Anonymous 角色可以使用公开区域资源但是不能改变任何物件。你可以修改预设的安全设定，但是大部分的时候你会发现这样的预设值已经足够。

之前我们已经提过只有你进入保护资料区时才会提示你登入以让 Zope 来核对你的身分，所以即使你已经有一个使用者帐户，在你还未登入之前，Zope 都会把你当成anonymous 的使用者来对待。

Zope Emergency User

Zope 提供一个紧急使用时的使用者身份 emergency user，我们已经在第二章讨论过这个身分，emergency user 不会受到正常的安全限制所限制。不过这个身分不能新增除了使用者之外的任何物件。

所以 emergency user 只可以做两件事，修正错乱的权限与建立 manager 帐户。如我们在第二章所见，你可以用 emergency user 登入来建立一个 manager account。建立好 manager 帐号后，你就可以登出 emergency user 身分后再用 manager 帐号登入系统进行例行的管理工作。

另一个用 emergency user 的时机是你自己被设定不当的权限锁住而无法管理 Zope，这时你可以用 emergency user 登入来确认你的 manager 帐号有适当的 View management screens 权限设定，修改完后先登出后再以你的 manager 帐号登入这时你应该就可以正常管理你的网站。

一个常见的错误是试图用 emergency user 去建立新的物件。

Figure 6-2 错误在试图建立新物件时用的是 Emergency User 身分。

Figure 6-2 的错误是让你知道 emergency user 不是万能的，他不可以建立新的物件，至于这样做的理由有点复杂，但是在接下来介绍所有权 ownership 时会更加清楚。简单的说就是这样做并不安全，因为 emergency user 如果可以建立物件，这个物件将不像其他物件一样受安全限制。

建立一个 Emergency User

这个帐号与其他的帐户建立的方式不同，它不能经由 web 介面建立，所以 Emergency User 帐号必须被定义在档案系统上，你可以修改 zope 目录下的 access 档来修改 emergency User 帐号，不过 Zope 附有一个命令列的工具 zpasswd.py 来管理 Emergency User 帐号，执行 zpasswd.py 并传入 access 档案路径如下:

          $ python zpasswd.py access

          Username: superuser
          Password:
          Verify password:

          Please choose a format from:

          SHA - SHA-1 hashed password
          CRYPT - UNIX-style crypt password
          CLEARTEXT - no protection.

          Encoding: SHA
          Domain restrictions:         

执行 zpasswd.py 会引导你建立一个 Emergency User 帐号，注意你输入密码资讯时并不会显示在萤幕上。你也可以执行 zpasswd.py 但是不提供参数资讯，这样会列出所有的命令列参数。

Zope Initial Manager

这个 Initial manager 帐号是由 Zope installer 建立来让你第一次登入 Zope 时使用。当你安装 Zope 过程中应该会有下面的讯息:

          creating default inituser file
          Note:
                  The initial user name and password are 'admin'
                  and 'IVX3kAwU'.

                  You can change the name and password through the web
                  interface or using the 'zpasswd.py' script.

这个讯息告知你 initial manager 的名字与密码，接下来你可以用这个资讯来第一次登入 Zope ，藉由这个身分你可以在新增其他的使用者帐号。

Initial users 建立的方式和 emergency user 一样，这个使用者被定义在 inituser 的档案之中，也同样以 zpasswd.py 来编辑这个使用者:

          $ python zpasswd.py inituser

          Username: bob
          Password:

          Verify password:

          Please choose a format from:

          SHA - SHA-1 hashed password
          CRYPT - UNIX-style crypt password
          CLEARTEXT - no protection.

          Encoding: SHA
          Domain restrictions:    

上面的过程会建立一个新的 initial user 称为 "bob" ，并设定密码完毕。当 Zope 启动时它会比对这个档案确认哪些人可以登入 Zope。一般来说 initial user 是由 Zope installer 建立，你不需担心如何建立这个使用者。如果你要建立其他的使用者，你可以经由 Zope web management interface 来进行。

到目前为止，我们已经说明如何用使用者与 user folders 来控制证明身分的部分，接下来我们要看看如何用安全政策来控制授权。

授权与管理安全性

Zope 藉由安全政策 security policies 来控制授权，也就是定义出谁可以在这套系统中作哪些事。安全政策描述出哪种角色有哪种权限。用角色来标示出一群使用者，再用权限来保护系统中的物件。所以安全政策会定义出在限定的区域中，哪一群使用者 (roles) 可以做哪些事 (permissions) 。

除了指定特殊群的使用者可以做哪些事之外，Zope 还可以将这些安全方面的设定限在网站的某个区域，这让你的安全政策简化但是非常具有威力。当然你也可以设定一些安全政策的例外，让特定的使用者，动作与物件不受安全政策限制。

在接下来的部分我们将藉由建立一个简单的安全政策来检视角色 roles 与权限 permissions，还有安全政策。

扮演角色

Zope 使用者藉由角色来决定它可以在系统中进行哪些工作，角色定义出一群进行相关工作的身分，像是 Manager, Anonymous 与 Authenticated。

角色类似 UNIX 系统中的 groups 概念，是一群人的抽象说法，同时和 UNIX groups 一样，Zope 使用者可以有一个以上的角色。

角色让安全管理更加容易，如果替每个人定义安全规则会非常繁琐而不易管理，藉由归纳出适当的角色，然后再替每种角色定出不同的安全政策会是比较简单的做法。

Zope 内建 4 种角色 :

Manager

这个角色用来管理标准的 Zope 管理功能，像是建立或编辑 Zope folders 与文件这类的工作。 Anonymous Zope Anonymous 使用者就归到这个角色控管，这个角色预设会被授以浏览公开区域之权限，而且不能建立任何物件。 Owner

这个角色是自动指派给建立物件的使用者，等一下会在所有权时一并说明。

Authenticated

这个角色是自动指派的，当使用者提供适当的身分证明后，就会被指定为这种角色。这种角色的含意就是 Zope "知道" 这个使用者是谁了。

一般的 Zope 网站可能只要 Manager 与 Anonymous 即可运作，但是比较复杂的网站你可能要归类你的使用者然后建立自己的角色来使用 zope。

定义角色

要建立自己的角色必须到 Security 页面下，卷到最下面可以输入新的角色名称在 User defined role 栏位之中。按此加入角色，角色名称最好简洁说明出这群人的特色，像是 "Author", "Site Architect" 或是 "Designer"，而且与你的应用程式是可以搭配的。

藉由角色栏最上方是否出现你定义的新角色来看看你的新角色是否设定完成，你也可以在下方的下拉列表中找到这个角色然后删除，注意列表中只有出现你定义的角色，关于 zope 的四大角色你是不能删除的。

必须注意角色生效的区域是以建立角色所在目录以下算起，所以要建立一个全站可用的角色就必须到根目录建立这个角色才有效。

一般建立角色的原则是尽可能的全站大部份区域都可以适用，如果你发现你建立角色只是为了限制进入网站的部分区域，那你可以采用比较好的方式来做，像是替现有的角色加上你希望限制的区域，或是在该区域下建立专有的 user floder 来管控，接下来我们会看到更多关于安全政策设定方面的范例。

了解区域角色

Local roles 区域角色是 Zope 安全的进阶功能。使用者可以被赋予额外的角色来处理特定的物件，如果一个物件设有区域角色给某一个使用者，则这个使用者处理这个物件时就具有这个角色的授权。

举例来说，如果一个使用者拥有一个物件时，通常也会替这个物件加上一个区域角色 Owner 给拥有者，这时虽然这个使用者没有扮演具有编辑 DTML Methods 的角色，但是他仍然可以编辑这个他拥有的 DTML Methods 物件。这时他扮演的角色就是区域角色。

区域角色是相当进阶的安全功能，但是并不会常常用到，Zope 自动指派 Owner 的区域角色是你少数会遇到这个功能的地方。

你会想要手动调整区域角色的主要原因是你想给某个特殊使用者对某个物件有特殊的存取权，但是一般来说你应该避免为某些使用者开此特殊权限，建立角色给一群使用者同样的权限会比较好管理。

了解权限

权限定义可以对物件进行的活动，就像角色是象征一群共同任务的使用者，权限则是抽象化物件活动，举例来说许多 Zope 物件可以被浏览，而这个可被浏览的活动就是利用 View permission 来控制与保护。

有些权限只对特定物件有作用，举例来说，修改 DTML Methods 权限只会保护 DTML Methods，对其他物件无效。但是也有可以适用许多种类物件的权限，像是 FTP access 与 WebDAV? access 权限等，这两种权限不限种类，但是限制是否可以进行 FTP 与 WebDAV? 活动。

你可以在每个物件的管理页面上方的 Security management 页面下查看这个物件的权限。

Figure 6-3 一个 mail host 物件的安全设定。

如 Figure 6-3 所示，mail host 物件只有少数有限的权限可以设定，对比起来，folder 的权限设定就比较多。

定义安全政策

Security policies 安全政策等于是角色与权限相遇的地方，安全政策定义在特定区域中，谁可以做甚么。

你可以设定安全政策影响所有的 Zope 物件，要设定安全政策请到 Security 页面，举例来说，在 root folder 下的 security 页面如下。

Figure 6-4 Security policy for the root folder.

Figure 6-4 图中有许多东西，萤幕中间是一个表格状的核对框供勾选，这个表格就是呈现整个安全政策的外观，垂直的栏位表示的是角色，水平的则是权限。勾选则是代表垂直栏角色在这个 root floder 区域，具有水平列赋予的权限。

你可以发现 Zope 有预设好安全政策， 就是让管理者可以进行大部分的管理工作，但是 anonymous 就少很多。你可以改变整个站的安全政策，就是在这个 root folder 进行设定即可。

举例来说，你可以将网站转为私有会员制，只要取消 anonymous 角色的浏览 view 权限即可，要这样做只要将 View 权限的核可取消即可，这样做的安全政策会影响全站，如果你只是要保护某些区域，只要在这个区域下如上法炮制即可。

这个范例说明安全政策一个非常重要的观念，安全政策只能影响特定区域，唯有 root floder 下的安全政策会遍及全站。

安全政策的取得

至于上下政策不同时该如何运作 ? 我们已经替不同物件建立不同的安全政策，但是如何确认物件到底适用哪种政策 ? 答案是物件会使用自己的安全政策优先，然后它再根据上一层的权限决定，这样的过程称为 acquisition。

Acquisition 取得是 zope 中档案夹分享物件资讯的特殊机制，至于 Zope 的安全系统一样利用 acquisition 来分享安全政策给下一层的物件。

你可以控制安全政策的取得，注意在安全页面的表格左边会有一栏 Acquire permission 的设定，预设值是会直接从上层取得安全政策，必须注意的是 root folder 既然是最上层，自然没有取得的权限栏位让你勾选。

所以假设你要让你的 folder 变成私有区域，如之前所说，只要取消 Anonymous 角色的 View 权限即可，但是如果你看该 floder 的安全设定时，你会发现 Anonymous 角色并没有勾选 View 权限，按理说这个目录应该是不能被浏览才对，但是测试看看去发现还是可以直接浏览，为甚么 ? 答案是 Acquire permission 设定所起的作用，这里虽没有设浏览权限，但是它的 Acquire permission 却是勾选的，这代表这个目录受上层目录的安全政策影响，所以在这个目录的上面某一层目录的 Anonymous 角色被设有 View 权限。如果你要摆脱上一层的影响让这一层目录变的私有，只要将 Acquire permission 取消，然后订出这个目录自己的 view 权限即可。

一般来说为了使安全政策可以影响全站，你应该避免取消 acquire 权限设定，除非你有特殊的理由需要这样做，但是这样做之后你就必须知道你在 root floder 下设的安全政策会有所例外，不会通行全站。

接下来我们会说明一些范例，看看如何用上面的观念来设定一个有效率的安全政策。

安全使用的式样

关于 Zope 安全的设定非常简单 : 利用角色与权限组成安全政策，使用者活动则受此政策控制。然而这些简单工具可以组成许多不同的方式，这会让管理变的复杂，所以为了让你可以有效率的制定出容易管理的安全政策，我们提供一些好的范例供建立安全政策时参考。

安全基本原则

这里有一些简单的指引供 Zope 安全管理参考，下面这些指引可以帮你面对那些不在你预料之中的不速之客。

1. 定义使用者在控制的最高层，而不是上一层而已。 2. 群聚那些由相同人管理的物件到同一个 folder。 3. 保持简化。

规则 1 和 2 的关系比较密切，两者都是 Zope 网站架构的基本原则之一，一般来说你应该常常重新整理你的网站，尽量让相关的使用者与资源互相接近，即使不能将资源与使用者都放在同一个目录与次目录结构下，但是适当地将资源和使用者放到同一个目录与次目录下对网站管理会有很大的帮助。

不管你的网站结构如何，保持安全设定简化非常重要，因为设定越复杂，就代表越难懂，越难管理，更别谈设的更有效率了。举例来说，限制角色的数量和尽可能用安全政策取得的机制来减少特定的设定需求。如果你发现你的安全政策与角色还有使用者之间的关系趋于复杂，你可能要重新思考可有较简单的方式。

全区与区域政策

最基本的设定就是在根目录下订出一个全区适用的安全政策，藉由安全政策预设向上层取得的机制扩及全站。接下来你才在特殊区域订出与全区安全政策不同的区域政策，尽量减少区域安全设定去覆盖全区安全设定。如果你发现你必须在许多不同地方订出区域安全政策，那你可以考虑将这些物件重新整理到同一个目录下，这样你就不用管理许多的区域政策。

你应该选择取得上一层的设定的方式，除非你在这一层的安全设定是比起全区安全政策更为严格。这时候你就要将这个取得的设定加以取消，代表以这个区域安全政策为主，不受上层安全政策影响。

这个简单的设定情节已经够符合你大部分的需要，这样做的好处可以让你容易管理与理解，而易于理解正是设定安全政策的重要考量因素。

委派给区域管理者

这种安全做法是 Zope 的核心，同时也是 Zope 的特色。Zope 鼓励你将同一类资源放在同一个目录下后建立一个使用者帐号来管理这些内容物件。

举例来说你要将 Sales 目录指派给新的业务网站管理员 Steve。首先你不希望 Steve 会去动到 Sales 目录以外的网站内容，所以不要将他加到根目录下的 acl_users folder 去，取而代之的是建一个全新的 user folder 在 Sales 目录下。

现在你可以将 Steve 加到 Sales 目录下的 user floder 去，然后再给他 Manager 角色扮演。这时 Steve 就可以登入 http://www.zopezoo.org/Sales/manage 去管理业务销售事宜。

Figure 6-5 Managing the Sales folder.

注意在 Figure 6-5 中左边的树状浏览区是以 Sales 当成这一区管理者进入时的根目录，区域管理员并没有权限去动到他所在根目录位置上层的事务。

这种安全设定的强而有力是因为可以重复应用到下一层去，举例来说， Steve 可以建立不同的次目录给多层次传销业务部门，然后再建立一个 user folder 在多层次传销的目录下来委派其他管理员管理多层次传销业务部门的网站事务。借由委派的安全设定可以让管理成千人应用的网站变的比较简单。

这样设定的好处是上层的管理者不用每件细微的修改都需要去管，藉由委派的做法，可以避免管理者处理许多繁琐的细节，但是又不会给被授权的区域管理者太多权限去动到网站其他区域。

不同存取等级的角色

使用区域管理员的做法确实十分具有威力与弹性，但是这样只能全部存去与全部无法存取的做法仍不够细致，有时候你需要定比较细的时候，特别是你的资源不是只给特一种人使用的时候，角色就是你的答案。角色允许你定义一群人到同一种角色，然后你在设定这种角色的安全政策。

建立角色给你更细致的安全设定，同时也代表更复杂与难以管理，所以当你要新增一个角色时必须确定你真的需要这个角色。举例来说你有一个网站公布文章让公众阅览，公众读文章，管理员编辑与公布文章。但是还有第三种角色存在，就是作者，你需要订出一个 author 角色来写文章，但是不能公布与编辑文章。

一种做法是建一个 authors 目录来放 author 的使用者帐号，并委派管理员角色给这些作者。这个目录只有作者可以阅览，所以文章可以在这个目录下面写好，再由管理者将文章由这个目录移出去公布。这是一个合理的设定，但是这让作者指可以在 authors 目录下活动，而且需要管理者额外处理文章移出 authors 目录的动作。还有，想想当作者想要更新文章但是文章又已经移出 authors 目录时，管理员要做多少事。

一个较好的解决方案是新增 Author 角色，加上一个角色可以突破上述的区域受限问题，所以在我们上面的范例中，藉由加入作者角色可以让文章不管放在全站的哪一个区域，都可以撰写，编辑与公布文章。我们可以藉由一个全区安全政策给作者去建立与撰写文章，但是不给作者公布与编辑权限。

角色可以让你根据谁来授权，而不受区域限制。

用角色控制区域存取

角色还可以帮你解决另一个区域管理员安全设定会导致的问题，这就是因为区域管理员的安全设定需要严格的目录控制，也就是针对同一目录下的资源只有区域管理者可以管理，所以不能某一区定义一个区域管理员，然后又让他管另一区域。

让我们用一个范例来说明区域管理员的安全设定的第二种限制，假设你管理一个大型药物公司的网站，而你有两类的使用者需要使用你的网站，科学家与业务员。以一般的情形来说，科学家与业务员应该是会使用不同类型的资源而互不相干，然而这里假设广告上需要加注科学用语的警语而使这两群人有所交集。这时候因为科学家放在 Science 目录下，但是业务员却在 Sales 目录下，那我们要放 AdsWithComplexWarnings? 目录在哪里 ? 除非说 Science 目录位于 Sales 目录之下，或是相反，不然根本没有办法找到地方放 AdsWithComplexWarnings? 目录可以同时给这两群人来同时管理，但是实务上又不可能让业务员来管理科学家的网站资源，或是科学家管业务。

解决这个困难的方式就是角色，你应该在 Science 与 Sales 目录之上建立两个角色， Scientist 与 SalesPerson?。然后在这一层新增这两种角色的使用者，而不再使用区域管理员的做法。这样一来这两群人都可以存取 AdsWithComplexWarnings? 的目录。

但是当你建构使用者采用这种高一层的做法时，你不该设定管理员角色给使用者，而是给适当的 Scientist 或是 SalesPerson? 角色。然后你再设定安全政策。在 Science 目录下，Scientist 角色与管理员有一样的授权，至于 Sales 目录下，Salesperson 角色则取得 Manager 的权限。最后在共同合作的 AdsWithComplexWarnings? 目录下，你可以设定适当的权限给 Scientist 或是 Salesperson 角色。这时角色不是用来提供不同等级的存取，反而可以提供存取不同区域的资源。

另一个你可能会采用这个设定方式的原因是你不能设你的区域管理员时可以使用。举例来说你可能用到不同的 user folder 产品，他可能会要求所有的使用者必须被定义在根目录才可以。这时你就可以用角色的设定来限制存取区域。

我们已经谈论过安全设定方式，这时你应该对于如何正确使用 user folders, roles 与安全政策有足够的理解。接下来我们会谈论两个进阶安全议题，执行安全检查与安全执行内容。

执行安全检查

大部分时间你都不会进行任何安全检查，如果使用者试图执行一个安全性操作，Zope 会提示使用者登入再执行。如果没有权限，Zope 会拒绝使用者存取。然而有时候你可能需要进行手动的安全检查。至于这么做的原因是你希望减少提供给认证过使用者的选项。这不能避免恶意扰乱者，但是可以减少正常使用者用错会遭遇的挫折。

最常见的安全查询就是现在的使用者具有的权限，举例来说你的应用程式让一些使用者可以上传档案，而这个活动受到 "Add Documents, Images, and Files" 这个标准的 Zope 权限控制，你可以在 DTML 中看看使用者是否具有权限:

      <dtml-if expr="_.SecurityCheckPermission(
                    'Add Documents, Images, and Files', this())">

        <form action="upload">
        ...
        </form>

      </dtml-if>

这个 SecurityCheckPermission? 功能需要两个参数，一个是 permission 的名称，还有这个物件。这里我们传 this() 当成目前物件的代表。藉由传递目前的物件，我们可以确认当测试这个使用者是否具有权限时，区域角色也会被考虑到。

你可以查出目前的使用者是谁，所谓的目前的使用者也是一个 Zope 物件，就像其他的物件相同，你可以在这个物件上执行提供的 API 。

架设你想要再网页上秀出目前的使用者，你只要用下面 DTML 即可:

      <dtml-var expr="_.SecurityGetUser().getUserName()">

藉由 SecurityGetUser? 你可以取得一个现在登入的使用者，这个 dtml 的片段表示执行登入使用者物件上的 getUserName method ，如果使用者没有登入，就会取得 Anonymous 的使用者名称。

接下来我们将检阅另一个影响 DTML 与 script 的进阶议题。

进阶安全议题 : 所有权 Ownership 与可执行内容 Executable Content

你已经具备基本的 zope 安全概念，只剩下进阶的所有权与执行内容。Zope 会用所有权来连结到哪个使用者建立这个物件，同时用可执行内容 executable content 代表那些可以执行程式的 Scripts, DTML Methods 与 Documents 。

对于小型网站来说，信任使用者的话不需要考虑这些进阶议题，但是对于大型网站提供不信任的使用者建立与管理 Zope 物件时，了解所有权与安全的可执行内容就是非常重要的事。

问题: 特洛埃木马攻击

会要对 ownership 与 executable content 进行控制最主要的动机是预防 Trojan horse attack，一个木马攻击就是误导使用者进行有害系统的行为。典型的木马程式常常是看起来无害，但是你执行时却会造成危害的程式。

所有的 web-based 平台，包括 Zope 都必须面对这类攻击，诱骗使用者指到一个URL 来进行危害系统的行为。

这类攻击相当难以防范，因为要让引导使用者去进入某个连结实在非常容易，更别说加上进阶的技巧，像是利用 Javascript 引导执行有害 URL。

Zope 提供一些保护来防止木马，Zope 藉由 server-side 端判别谁建立这个物件来限制执行权限，所以如果一个 untrusted user 建立一个物件可以删除所有网站物件，这时当他们要浏览这个网页试图执行时会因为他们没有权限而无法浏览，但是管理者有足够权限也不会执行删除所有物件的动作而危害系统，就因为这是不信任的使用者所建立的物件。

Zope 就是使用所有权与可执行内容两者就是提供上述防范的答案。

管理所有权

当一个使用者建立一个物件，他们就拥有这个物件。没有所有权的物件会标为 unowned，所有权的资讯是烧在物件上的，就像 UNIX 对待档案的所有者资讯做法一样。

只要你浏览物件的 Ownership 页面就可以知道物件所有人是谁。秀在下图 Figure 6-6 中。

Figure 6-6 Managing ownership settings.

这个画面会告知物件是否有主，以及主人是谁的资讯。如果这个物件有主，但是你又具有 Take ownership permission 权限，你就可以接管别人的物件。你还可以一次接管所有依附的次物件，只要勾选 Take ownership of all sub-objects 即可。接管所有权常用在被删除使用者所有的物件上，或是这个物件已经移交你管理。

前面我们有稍微提到所有权对安全政策的影响，这是因为所有者会在这个物件上有一个区域角色称为 Owner 。所有权还会影响到安全的另一个因素是所有权控制角色的可执行内容。

可执行内容的角色

经由网站介面你可以替一些物件编辑 scripts ，像是 DTML Documents, DTML Methods, SQL Methods, Python-based Scripts 与 Perl-based Scripts。这些物件都是可执行物件，但是可以在网站上编辑的。

当你浏览可执行物件的 URL 时就会呼叫程式执行，这些 script 是被限制在物件的所有者角色与你的角色才可以执行。换句话说，一个可执行的物件只可以在所有者与浏览者都是被认证通过的才可以执行。如此一来可以避免无权的使用者写的一个有害的 script 让有权限的人执行。你并没有办法让某些人去执行他没有执行权的内容。这就是 Zope 如何在 server-side 端防范 Trojan horse 攻击的方式。

代理人角色

有时 Zope 对可执行内容的系统防护不能符合你的要求。你想要不管所有权来降低执行的安全限制时，或是你想要提供可执行的物件给没有授权的人来执行这个被保护的行为时，代理人角色 Proxy roles 可以提供你一个调整可执行物件权限的方法。

假设你想要给无记名的使用者寄 email 给网站管理员的权限，寄出 email 这个行为受到 Use mailhost services permission 控制保护，Anonymous 使用者通常不会有这个权限。通常不会给无记名的使用者乱寄信的权限。

但是你又需要无记名的使用者可以用 DTML Method 来寄信，你就可以应用代理人的这个角色 proxy roles 在 DTML Method 上。这让执行这个寄信动作取得代理 "Manager" 角色的功能。你可以在你的 DTML Method 上面的 Proxy 页面看到这类设定如下图 Figure 6-7.

Figure 6-7 Proxy role management.

选择 Manager 后按下 Change 就可变更代理人角色。这就让这个寄信功能取得管理员的代理角色。注意你必须有 Manager 角色才可以设定 proxy 角色。这时就算无名氏没有你的系统寄信权限，他还是可以以管理员的代理人身分执行寄信的动作。

代理人角色定义一个有限的权限给可执行内容，所以你也可以反过来限制物件的安全，举例来说，你可以设一个 script 给 Anonymous 的代理人角色，这时这个 script 将不会被 Anonymous 以外的角色执行，即使你是所有者的角色或是浏览者的角色都一样。

使用 Proxy 角色必须小心，因为这会影响到预设的安全限制。

结论

安全由两个程序组成，证明 authentication 与授权 authorization。利用 User folders 来控制安全中的证明程序，用安全政策来控制授权程序。Zope 安全性与所在位置有紧密的相关，使用者有其所在位置，安全政策也有所在位置，甚至连角色也有所在位置。要建构一个有效的安全架构就不得不注意所在位置的资讯，特别是当你对本章所提的安全使用样式有所疑问时。

接下来我们将谈论进阶的 DTML，DTML 可以变成一个强力的展示与 scripting 工具。你会发现许多新的 tags 说明，还会看到一些 DTML-specific 特殊的安全控制议题。

From leera Mon Apr 5 13:16:36 +0800 2004 From: leera Date: Mon, 05 Apr 2004 13:16:36 +0800 Subject: 修订? Message-ID: <20040406051636+0800@www.czug.org>

"建立自己的角色必须到 Security 页面下" to "建立自己的角色必须到 group的Security 页面下"

From leera Mon Apr 5 13:20:23 +0800 2004 From: leera Date: Mon, 05 Apr 2004 13:20:23 +0800 Subject: 这个文档里面没有写"reviewer" Message-ID: <20040406052023+0800@www.czug.org>

最新的zope里面默认有如下角色: Anonymous Authenticated Manager Member Owner Reviewer reviewer我还不是很明白.