这两天我的本本出问题了，老是显示屏变黑，修已经修了七百多大洋了，可还是过了几个月又坏了，没见好，真是郁闷呀！得出的结论是象这种万元以内的本本 （我用的是京东方T200）还是少买为妙。要么不买，要么就买万五以上的，省了的那五千块大洋，会让你的一年之后觉得特别闹心！而且修理费也很多了，我这 还是由于在保修期内，所以换的那个显示屏没要钱，不然的话，也省不了多少！现在的本本时好时坏，趁着还没罢工之前，我还是多贴点吧！

Naming Access Objects
权限对象的命名

phpGACL uniquely identifies each Access Object (AROs, AXOs and ACOs) with a two-keyword combination and it's Access Object type.
phpGACL系统用双关键字组合唯一标识每一个权限对象（ARO、AXO或ACO对象），并且它是权限对象类型。

The tuple "(Access Object type, Section, Value)" uniquely identifies any Access Object.
它是用元组（权限对象类型，节，值）的形式来唯一标识权限对象的。

The first element of the tuple is the type of Access Object (ARO, AXO or ACO).
第一个元组元素是权限对象类型（ARO、AXO或ACO）。

The second element of the tuple, called the Section, is a user-defined string which names the general category of the Access Object. Multiple Access Objects can share the same Section name. The Section name should be short but descriptive. It's used in the user interface in selection boxes, so try not to make it too long.
元组的第二个元素叫节，它是由用户定义的命名权限对象通用类的字符串。多权限对象可以共享同一节名，节名很短但却是描述性的，它常被用在用户界面中的选择框中，因此不要它定义得太长。

Sections are stored in a flat namespace; they are not nestable like Groups. Sections have nothing to do with Groups or the ARO/AXO trees - they are purely a mechanism for helping to maintain large numbers of Access Objects.
节被保存在平的名称空间中，它不象组那样可以嵌套使用。节并不组或ARO/AXO树中做任何事，它仅仅只是为了帮助维护大量的权限对象。

The third element of the tuple is a user-defined name for the Access Object, and is called the Value. A Value cannot contain spaces (however, a Section can).
元组的第三个元素叫值，是用户定义的权限对象名称，值中不能包含空格（而节可以）。

Both Section and Values are case sensitive.
节和值都是大小写敏感的。

Aside: It is commonly asked why strings are used to identify Access Objects, rather than integers which ostensibly seem faster. The answer is for legibility. It is much easier to understand:
另：为什么用字符串来标识权限对象而不用看上去更快的整数呢，原因是为了易读性，从下例可以看出用
acl_check('system', 'login', 'users', 'john_doe');
than：

比用:
acl_check(10, 21004, 15, 20304);
更容易理解。

Since it is often obvious from the context which type of Access Object we are referring to, the interface for phpGACL (and this documentation) drops the Access Object type and uses the format "Section > Value" when displaying the name of an Access Object. However, the API requires an Access Object's "Section" and "Value" to be specified in separate function arguments (the Access Object type is usually implicit in the argument description).
因为通过上下文可以十分清楚我们所指定的权限对象类型，所以phpGACL（和本文档）在显示权限对象名时都去掉了权限对象类型而只需要采用"Section > Value"格式就成了。而在API中则要求权限对象的"节"和"值"必须要在函数参数中分别指定（权限对象类型在参数描述中通常是不明白指定的） Example ACO "Section > Values":
例如 ACO对象的"节>值"
  • "Floors > 1st"
    "    楼层>一楼"

  • "Floors > 2nd"
    "    楼层>二楼"

  • "Rooms > Engines"
    "    房间>发动机室"

Example ARO "Section > Values":
例如 ARO对象的"节>值"

  • "People > John_Smith"
    "    人>John_Smith"

  • "People > Cathy_Jones"
    "    人>Cathy_Jones"

  • "Hosts > sandbox.something.com"
    "    主机>sandbox.something.com"

Example API usage:
例如 API的用法：

  • acl_check ( aco_section, aco_value, aro_section, aro_value);

  • acl_check ( 'Floors', '2nd', 'People', 'John_Smith' );

Valid Naming Restrictions Examples:
合法的命名限制实例：

  • "ACO -Frob > Flerg", "ARO - Frob > Flerg" (The Section and Value are the same in both, but this is fine as namespaces are separate across Access Object types)
    "ACO -Frob > Flerg", "ARO - Frob > Flerg"     （虽然节和值都相同，但这种命名是合法的，因为名称空间被权限对象类型给区分开了）

  • "ACO -Frob > Flerg", "ACO - Frob > Queegle" (The Access Object type and Section are the same, but this is fine as the Values are different)
    "ACO -Frob > Flerg", "ACO - Frob > Queegle"     （虽然权限对象类型和节名都相同，但由于值名不同，所以该命名合法。

  • "AXO - Frob Hrung > Flerg" (Sections can contain spaces)
    "AXO - Frob Hrung > Flerg"     （节名可以包含空格）
Invalid Naming Restrictions Examples:
不合法的命名限制实例：

  • "ACO - Frob > Flerg", "ACO - Frob > Flerg" ("Access Object type - Section > Value" must be unique)
    "ACO - Frob > Flerg", "ACO - Frob > Flerg"     （"权限对象类型-节名>值名"必须是唯一的）

  • "ACO - Frob > Flerg Habit" (Values cannot contain spaces)
    "ACO - Frob > Flerg Habit"     （值名中不能包含空格）

Adding Sections
添加节

Before you can add a new Access Object, its Section must be defined. To add a new section, use the add_object_section() function.
在你能添加一个新的权限对象之前，它的节名必须已经被添加。添加一个新的节名，可以使用add_object_section()函数。 add_object_section ( string NAME, A short description of what this Section is for. (e.g. "Levels in building").
简单描述该节的用处（如"Levels in building"）

string VALUE, The name of the Section (e.g. "Floor").
节名（如"Floor"） int ORDER, An arbitrary value which affects the order this Section appears in the UI.
可以是一个任意的值，表示该节在用户界面上出现的次序 bool HIDDEN, Whether this should appear in the UI or not (TRUE means that is will be hidden).
表示该节是否出现在用户界面中（如果是TRUE则意味着它将被隐藏）。 string GROUP_TYPE) The Access Object type ("aco", "aro" or "axo")
权限对象类型（"aco", "aro" 或 "axo"）

Han creates 3 Sections for the AROs. "Humans", "Aliens" and "Androids". Let's list the AROs with their full names
Han为ARO对象创建 了三个节，它们分别是"人类"，"外星人"和"机器人"。让我们用它们的全名来列出ARO对象列表。

缺省：全部拒绝
千年隼号乘客
├─船员 [允许：全部]
│├─"人类 > Han"
│├─"外星人 > Chewie" [拒绝：发动机室]
│└─"人类 > Lando"
├─乘客 [允许：休息室 ]
│├─绝地战士 [允许：驾驶室]
││├─"人类 > Obi-wan"
││└─"人类 > Luke" [允许：武器室] 
│├─"机器人 > R2D2" [允许：发动机室]
│└─"机器人 > C3PO"
└─工程师 [允许：发动机室，武器室]
├─"人类 > Han"
├─"机器人 > R2D2"
└─"外星人 > Hontook"

Sections are just a way of categorizing Access Objects, to make the user interface more usable, and the code for acl_check() more readable. They do not affect the way phpGACL determines access to an object. They cannot be nested (so it would not be able to create a "Males" sub-Section under "Humans" for example; you'd have to create a Section called "Humans-Male" or similar)
节仅仅只是一种权限对象的分类方式，以便使得用户界面更加友好，acl_check()代码更具可读性。它并不影响phpGACL决定对象的权限。它不能被嵌套（因此它不能在"人类"节下更创建一个"男人"子节，你将不得不创建一个类似叫做"Humans-Male"的节）

Multiple Purposes
多目的

You may need to use phpGACL for multiple independent purposes. For example, you may need to restrict user access to web pages, and also remote host access to your server. The two tasks are not related.
你也许需要用phpGACL来实现多个不同的目的。比方说，你也许需要限制用户访问网页的权限，并且还想限制远程主机访问你的服务器的权限。这两个任务之间并没有什么联系。

phpGACL can handle this in three different ways.
phpGACL能通过下面三种不同的方式来处理。

  • It can use an alternative database to store the access tables.
    可以在另一个数据库中保存权限表单。

  • It can use the same database but with differently named access tables. (this feature is not implemented yet).
    可以在同一数据库中用不同的权限表单来保存。（该功能并没有实现）

  • You can store the Access Objects for both purposes in the same tables, and carefully manage your list so that they don't conflict.
    你可以在同一个表单中保存权限对象的不同目的，并小心地管理你的列表以使它们不再冲突。

To implement Option 1 (and Option 2 when it becomes available), use the $gacl_options array when creating a new phpGACL class. This allows you to specify the database and table name prefixes to use:
可以在创建一个新的phpGACL类时通过$gacl_options数组就可以实现选项1（当选项2可以实现时也一样），该数组允许你指定数据库和表单名的前缀。

$gacl_options = array(
'db_table_prefix' => 'gacl_',
'db_type' => 'mysql',
'db_host' => 'host1',
'db_user' => 'user',
'db_password' => 'passwd',
'db_name' => 'gacl');

 

$gacl_host1 = new gacl($gacl_options);

To implement Option 3, you must be careful, since phpGACL doesn't know the relationship between your different tasks, and it will be possible to make meaningless Access Policy Directives.
为了实现选项3,你必须要十分小心，因为phpGACL并不清楚你不同任务之间关系，因此有可能会生成无效的权限策略。

For example, say Han wanted to restrict access to other ships contacting his ship's computer, in addition to restricting access to the different rooms. To do this, he might add "Luke's X-Wing Fighter" as a remote ship ARO (in addition to other ships and an ACO for the ship's computer). Because all AROs are in the same ARO tree, it would be possible to create an APD like "Ships > Luke's X-Wing Fighter" [ALLOW: "Rooms > Lounge"], which would be totally meaningless! To help reduce mistakes like this, good Section naming can make it clearer what Access Objects are for which tasks. It should be obvious to any administrator that it's meaningless to assign a Ship permission to use a Room.
举个例子来说：Han想限制其他飞船同他飞船计算机之间的联系，此外还要限制到不同房间的权限。为了做到这一点，他也许要添加"Luke的X型战斗机"作为远程飞船ARO对象（此外还可以添加其他飞机并且将飞船的计算机作为ACO对象）。因为所有ARO对象都在同一ARO树，因此创建一个APD就象"飞船 > Luke的X型战斗机"[允许："房间 > 发动机室"]一样，是完全没有意义的！为了帮助处理象这样的错误，好的节名能够使象这样的权限对象更加清楚。这对于任何管理员都是十分明显的：为一个飞船指定一个访问房间权限是没有任何意义的。

Access eXtension Objects
扩展权限对象

Access eXtension Objects (AXOs) can add a 3rd dimension to the permissions that can be configured in phpGACL. We've seen how phpGACL allows you to combine an ARO and an ACO (2 dimensions) to create an Access Policy Directive. This is great for simple permission requests like:
在phpGACL中可以通过配置扩展权限对象（AXO对象）为第三方添加权限。我们已经知道了phpGACL是如何将ARO对象和ACO对象组成一个访问控制策略指令的，这主要用于简单的权限要求象： Luke (ARO) requests access to "Guns" (ACO)
Luke（ARO对象）要求访问"武器室"（ACO对象）的权限 If that's all you need, that's fine - AXOs are totally optional.
如果这是你所需要的，那么AXO对象就完全是可选的了！ But because all ACOs are considered equal, it makes it difficult to manage if there are many ACOs. If this is the case, we can change the way we look at Access Objects to manage it more easily.
但是由于所有的ACO对象都是相同的，因此如果它们存在很多的话那管理起来将是困难的。如果是这样情况的话，我们可以通过改变思考权限对象方式来使其管理起来更加容易。 AXOs are identical to AROs in many respects. There is an AXO tree (separate from the ARO tree), with it's own Groups and AXOs. When dealing with AXOs, consider an AXO to take the old role of the ACO (i.e. "things to control access on"), and change the view of ACOs from "things to control access on" to "actions that are requested".
AXO对象在许多方面同ARO对象是一样的。这有一个AXO树（是从ARO树中分离出来的）有着自己的组和AXO对象。在处理AXO对象时，用以前看待ACO对象的方式看待AXO对象（象"需要权限控制的事物"），而改变看待ACO对象的方式，从"需要权限控制的事物"变成"被要求的运作"。 ARO and ACO-only View:
看待只有ARO和ACO对象的方式：
  • AROs: Things requesting access
    ARO    对象：要求权限的事物
  • ACOs: Things to control access on
    ACO    对象：需要权限控制的事物
ARO, ACO and AXO View:
看待ARO、ACO和AXO对象的方式：
  • AROs: Things requesting access
    ARO    对象：要求权限的事物
  • ACOs: Actions that are requested
    ACO    对象：被要求的动作
  • AXOs: Things to control access on
    AXO    对象：需要权限控制的事物
Example:
例如： A website manager is trying to manage access to projects on the website. The ARO tree consists of all the users:
一个网站管理员想要管理访问该网站中项目的权限。一个由所有用户组成的ARO树如下所示： Website（网站）
├─Administrators（管理者）
│ ├─Alice
│ └─Carol
└─Users（用户）
├─Bob
└─Alan The projects are organized by Operating System into categories in the AXO tree:
在AXO树中通过操作系统分类项目被组织成： Projects（项目）
├─Linux
│ ├─SpamFilter2
│ └─AutoLinusWorshipper
└─Windows
├─PaperclipKiller
└─PopupStopper The actions that can be taken with each project are "View" and "Edit". These are the ACOs.
对于每个项目而言，动作是"观看"和"编辑"。这些是ACO对象。 Now we want Bob to have "View" access to all the Linux projects, so it's possible to add an ADP that links Bob's ARO to the View ACO and the Linux AXO, and thus we can ask the question:
现在我们想要Bob对所有的Linux项目有"观看"的权限，因此可以添加一个ADP将Bob的ARO对象与观看的ACO对象和Linux的AXO对象连接在一起。于是我们可以问一个问题： Bob (ARO) requests access to "View" (ACO) the project(s) called "Linux" (AXO)
Bob（ARO对象）要求对一个叫Linux的项目（AXO对象）有"观看"（ACO对象）的权限 Keep in mind AXO's are optional, if you don't specify an AXO when calling acl_check() and a matching ADP exists with no AXO, it will be allowed. However if only APDs exist with AXO's, and you call acl_check() without an AXO, it will fail.
记住AXO是可选的，如果你在调用acl_check()函数时没有指明AXO对象或匹配到一个没有AXO对象的ADP，这是允许的。然而如果只有AXO对象的APD而你却调用没有AXO对象的acl_check()函数，那么系统将失败。 So basically as soon as you specify an AXO when calling acl_check(), acl_check() will only search ACLs containing AXO's. If no AXO is specified, only ACLs without AXOs are searched. This in theory (I haven't benchmarked) gives us a slight performance increase as well.
所以一旦你在调用acl_check()函数时指定了AXO对象的话，acl_check()函数就只搜索含有AXO对象的ACL列表。如果AXO对象没有被指定，那么只有不含有AXO对象的列表才会被搜索。基于上述理论也使系统在性能上有所提升。