This file is indexed.

/usr/share/phpgacl/docs/translations/russian/manual_rus.html is in phpgacl 3.3.7-7.3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>phpGACL - русская документация</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="author" content="Feskov Kuzma, http://russofile.ru/kuzma/">
<style>
BODY{color:Black;background-color:White;font-family:sans-serif;font-size:14px;}
TABLE.BORDER{border-color:#FFFFCC;border-style:Solid;border-width:3px;}
TD{font-family:sans-serif;font-size:14px;}
TD.CONTENT{padding:.5cm .5cm .5cm;}
A{color: #002080;text-decoration:none;}
A:hover{color:#D49000;}
P{text-indent:1cm;margin:0cm;}
PRE{font-size:14px;}
HR{color:#FFFFCC;}
H1{color:#FFD068;}
H2{color:#FFD068;}
H3{color:#FFD068;}
.P1{letter-spacing:2pt}
</style>
</head>
<body>
<h1>phpGACL - русская документация</h1>
Generic Access Control List
<br><br>
Mike Benoit (<a href="mailto:ipso@snappymail.ca">ipso@snappymail.ca</a>)<br>
James Russell (<a href="mailto:james-phpgacl@ps2-pro.com">james-phpgacl@ps2-pro.com</a>)<br>
Karsten Dambekalns (<a href="mailto:k.dambekalns@fishfarm.de">k.dambekalns@fishfarm.de</a>)<br>
Русский перевод Феськов Кузьма (<a href="mailto:kuzma@russofile.ru">kuzma@russofile.ru</a>) (<a href="http://php.russofile.ru" target="_blank">http://php.russofile.ru</a>)<br>
Copyright © 2002,2003, Mike Benoit<br>
Copyright © 2003, James Russell<br>
Copyright © 2003, Karsten Dambekalns<br>
Document Version: 672<br>
Last Updated: 5/20/03 - 18:55:08<br>

<h1>phpGACL</h1>
<h2>Что это?</h2>
<p>PhpGACL – это набор функций, который позволяет определить права доступа к произвольным объектам (например, страницам, базам данных и так далее) другим объектам (например, пользователями, удаленными хостами и так далее).
<p>Это предполагает подробный контроль доступа с простым управлением и высокой скоростью.
<p>Скрипт написан на PHP (отсюда его название – phpGACL) – это популярный скриптовый язык, который обычно используется для динамического создания страниц сети. GACL часть phpGACL – Родовой список контроля доступа.
<h2>Где взять?</h2>
<p>PhpGACL хостится на sourceforge.net здесь <a href="http://phpGACL.sourceforge.net/" target="_blank">http://phpGACL.sourceforge.net/</a>
<h2>Что нужно для запуска?</h2>
<P>PhpGACL требует реляционную базу данных для хранения информации о правах. Доступ к базе данных осуществляется через абстрактный класс доступа к базам данных ADOdb (<a href="http://php.weblogs.com/adodb" target="_blank">http://php.weblogs.com/adodb</a>). Данный класс позволяет работать с такими базами данных как: PostgreSQL, MySQL, Oracle.
<p>Поскольку phpGACL написан на языке PHP, то он требует установки PHP версии не ниже 4.2. ACL (Администрирование списка контроля доступа) дополнена веб-интерфейсом, потому необходимо наличие веб-сервера с поддержкой PHP, например, Apache (<a href="http://httpd.apache.org/" target="_blank">http://httpd.apache.org/</a>).
<h2>Авторы</h2>
<p>Mike Benoit (<a href="mailto:ipso@snappymail.ca">ipso@snappymail.ca</a>) – автор и менеджер проекта.
<p>James Russel (<a href="mailto:james-phpgacl@ps2-pro.com">james-phpgacl@ps2-pro.com</a>) и
<p>Karsten Dambekalns (<a href="mailto:k.dambekalns@fishfarm.de">k.dambekalns@fishfarm.de</a>) – авторы документации.
<p>Feskov Kuzma (<a href="mailto:kuzma@russofile.ru">kuzma@russofile.ru</a>) – русский перевод
<p>Последняя версия перевода всегда здесь: <a href="http://php.russofile.ru" target="_blank">http://php.russofile.ru</a>
<h1>Введение</h1>
<h2>Понимание контроля действия</h2>
<p>Хан – капитан “Сокола тысячелетия” и Чуви – его второй офицер. Они взяли на борт несколько пассажиров: Люка, Оби-Вана, R2-D2 и C3PO. Хан должен определить ограничения доступа для различных мест (комнат) корабля, например: кабина, машинный зал, двигатели и внешнее оружие.
<p>Хан сказал: “Я и Чуви могут иметь доступ всюду, но, после особенно грязного ремонта гипердвигателя, я запрещаю Чуви когда-либо подходить к машинному залу. Пассажиры ограничены пассажирским залом”.
<p>С этого момента, давайте будем считать, что доступ является Boolean (Булевым), то есть, результат запроса на доступ персонажа к какому-либо помещению является “Разрешить” или “Не разрешить”, и нет никакого среднего результата.
<p>Если мы нанесем это утверждение на матрицу доступа, показывающую, кто имеет доступ куда-либо, то это бы выглядело примерно так (O – доступ разрешен, X – доступ запрещен):
<table align="center" cellpadding="5" border="1">
    <tr>
        <td align="center">Кто / Куда</td>
        <td align="center">Кабина</td>
        <td align="center">Пассажирский зал</td>
        <td align="center">Оружие</td>
        <td align="center">Машинный зал</td>
    </tr>
    <tr>
        <td align="center">Хан
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
    </tr>
    <tr>
        <td align="center">Чуви
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">Оби-Ван
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">Люк
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">R2-D2
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">C3PO
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="red">X
    </tr>
</table>
<p>Колонки показывают список комнат, к которым Хан может ограничить доступ, а ряды показывают персон, которые могли бы запросить доступ к тем или иным комнатам. Более широкое объяснение:
<p>“комнаты” - это вещи (объекты) для управления доступа к ним. Мы называем эти объекты <strong>ACO</strong> (<em>Access Control Objects</em> - Объекты контроля доступа);
<p>“люди” - “вещи (объекты), запрашивающие доступ”. Мы называем их <strong>ARO</strong> (<em>Access Request Objects</em> - Объекты запроса доступа). Люди запрашивают доступ к комнатам, или, в нашей терминологии, AROs запрашивают доступ к ACOs.
<p>Так же есть третий тип объекта – <strong>AXO</strong> (<em>Access eXtension Objects</em> – Объекты расширения доступа), но о нем мы поговорим позже. Эти объекты имеют много атрибутов и упоминаются вместе как Объекты доступа.
<p>Управление доступом, используя матрицу доступа, подобной выше, имеет преимущества и недостатки:
<p>Плюсы:
<ul>
<li>очень подробный – есть возможность управления доступом на уровне конкретного человека, если есть такая необходимость;
<li>легко увидеть, <u>кто</u> имеет доступ и <u>к чему</u>. Ответ находится в пересечении человека и комнаты.
</ul>
<p>Минусы:
<ul>
<li>трудно управлять на крупной матрице доступа. 6 пассажиров и 4 места – это просто, но что, если у вас тысячи пассажиров и сотни мест, и вы должны ограничить доступ большими группами и сразу, но сохранить при этом подробный контроль для отдельного индивидуума? Это означало бы большое и трудоемкое регулирование матрицы, а так же поставило бы очень трудную задачу проверки матрицы на правильность;
<li>трудно суммировать и визуализировать. Предыдущий пример довольно прост, его можно записать в несколько предложений (смотрите высказывание Хана), но что, если матрица напоминает такую?
</ul>
<table align="center" cellpadding="5" border="1">
    <tr>
        <td align="center">Кто / Куда</td>
        <td align="center">Кабина</td>
        <td align="center">Пассажирский зал</td>
        <td align="center">Оружие</td>
        <td align="center">Машинный зал</td>
    </tr>
    <tr>
        <td align="center">Хан
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">O
    </tr>
    <tr>
        <td align="center">Чуви
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">Оби-Ван
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">Люк
        <td align="center" bgcolor="green">0
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="green">0
        <td align="center" bgcolor="red">X
    </tr>
    <tr>
        <td align="center">R2-D2
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">0
    </tr>
    <tr>
        <td align="center">C3PO
        <td align="center" bgcolor="green">0
        <td align="center" bgcolor="green">O
        <td align="center" bgcolor="red">X
        <td align="center" bgcolor="green">0
    </tr>
</table>
<p>Эта матрица не на столько очевидна для суммирования, и не понятна для читателя, почему те или иные решения были приняты.
<h2>Управление контролем доступа при помощи phpGACL</h2>
<p>Ясно, что для контроля над большими системами и сложными ситуациями этот подход “матрицы доступа” является неподходящим. Мы нуждаемся в лучшей системе, которая поддерживает плюсы (подробный контроль и понятную визуализацию того, <u>кто</u> имеет имеет доступ и <u>к чему</u>) и удаляет неудобства (трудность суммирования, трудность управления большими группами людей сразу). Одно решение – phpGACL.
<p>PhpGACL не описывает доступ от “восходящего” подобно матрице доступа выше. Вместо этого, описывает доступ сверху вниз, подобно текстовому описанию политики доступа Хана. Это – очень гибкая система, которая позволяет вам управлять доступом в больших группах, так же позволяет аккуратно суммировать политику доступа и легко видеть, <u>кто</u> имеет право на доступ и <u>к чему</u>.
<p>ARO-дерево определяет иерархию групп  AROs (объектов запроса доступа). Это подобно представлению дерева папок и файлов. “Папки” - группы, “файлы” - AROs.
<p>Давайте попробуем составить ACL-дерево для людей на судне Хана. Сначала мы определим некоторые категории для людей. Ясно, что Хан и Чуви управляют судном, а остальные объекты – это только пассажиры.
<pre>
Пассажиры Сокола тысячилетия    Группа
├─Команда                       Группа
│ ├─Хан                         ARO
│ └─Чуви                        ARO
└─Пассажиры                     Группа
  ├─Оби-Ван                     ARO
  ├─Люк                         ARO
  ├─R2-D2                       ARO
  └─C3PO                        ARO
</pre>
<p>Это дерево не определяет никакой политики, оно просто показывает, каким образом мы группируем людей, которые могли бы запросить доступ (AROs).
<p>Мы задаем ограничения доступа, создавая инструкции для определенной комнаты (ACO) какой-то группе или AROs в дереве. Хан говорит: “По умолчанию никому нельзя назначить доступ ни к одной из комнат на Соколе тысячелетия. Но команда должна иметь доступ к каждой комнате. Пассажиры должны иметь доступ только к пассажирскому залу”.
<pre>
Пассажиры Сокола тысячилетия
├─Команда                       [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ └─Чуви
└─Пассажиры                     [ALLOW: Lounge] (разрешить: пассажирский зал)
  ├─Оби-Ван
  ├─Люк
  ├─R2D2
  └─C3PO
</pre>
<p>Чтобы интерпретировать наше ARO-дерево, мы начинаем с вершины и двигаемся вниз.
<p>Во-первых, политика по умолчанию состоит в том, чтобы запретить доступ ко всему. Ограничения были изменены только для команды, так что они теперь имеют доступ ко всему (ALL – синоним для всех комнат (кабина, машинный зал, пассажирский зал и оружие). Пассажиры имеют только доступ к пассажирскому залу.
<p>Такой способ описывать политику доступа более ясен чем матрица доступа. Вы можете легко видеть кто имеет доступ к чему, а так же более легко определить, почему они имеют этот доступ (кажется очевидным, что Хан и Чуви имеют доступ ко всему, так как они сгруппированы в “Команду”).
<p>Суммируем:
<ul>
<li>ACO (объекты контроля доступа) – вещи, доступом к которым мы хотим управлять (например страницы сети, базы данных, комнаты и так далее);
<li>ARO (объекты запроса доступа) – вещи, которые запрашивают доступ (например, люди, отдаленные компьютеры и так далее);
<li>ARO-деревья – определяют иерархию <strong>Групп</strong> и AROs. Группы могут содержать другие группы и AROs;
<li>политика по умолчанию для дерева – запретить все  (DENY: ALL);
<li>чтобы определить политику доступа, двигайтесь вниз по дереву, явно назначая разрешения Группам и AROs для каждого ACO, если в этом возникает потребность.
</ul>
<h2>Подробный контроль доступа</h2>
<p>Ой, мы кажется забыли про Чуви! Отнеся его к команде Хан косвенно дал ему доступ в машинный зал! Но, если помните, он не хотел этого делать. Он не хочет этого после того, как Чуви недавно ремонтировал гипердвигатель. Хан добавляет правило запрещения для Чуви:
<pre>
Пассажиры Сокола тысячилетия
├─Команда                    [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ └─Чуви                     <strong>[DENY: Engines] (запретить: машинный зал)</strong>
└─Пассажиры                  [ALLOW: Lounge] (разрешить: пассажирский зал)
  ├─Оби-Ван
  ├─Люк
  ├─R2D2
  └─C3PO
</pre>
<p>Это пример того, как вы можете управлять политикой доступа в подробной манере. Нет необходимости перемещать Чуви в другую группу, мы просто запрещаем ему на более низком уровне.
<p>Другой пример подробного контроля может возникнуть, когда на корабль напала Империя. Хан должен позволить человеку Люку использовать оружие и позволить роботу R2D2 восстановить гипердвигатель в машинном зале. Он может сделать это расширив их полномочия, которые определены им общим статусом группы “Пассажир”:
<pre>
Пассажиры Сокола тысячилетия
├─Команда                    [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ └─Чуви                     [DENY: Engines] (запретить: машинный зал)
└─Пассажиры                  [ALLOW: Lounge] (разрешить: пассажирский зал)
  ├─Оби-Ван
  ├─Люк                      <strong>[ALLOW: Guns] (разрешить: оружие)</strong>
  ├─R2D2                     <strong>[ALLOW: Engines] (разрешить: машинный зал)</strong>
  └─C3PO
</pre>
<h2>Многоуровневые группы</h2>
<p>Группы могут быть расширены на любой уровень в ARO-дереве. Например, мы могли бы добавить группу “Джедаи” к “Пассажирам”. Большинство пассажиров было бы категоризировано при “Пассажирах”, но Люк и Оби-Ван будут выделены в “Джедаи” и поэтому могут иметь некоторые привелегии (например, доступ в кабину):
<pre>
Пассажиры Сокола тысячилетия
├─Команда                    [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ └─Чуви                     [DENY: Engines] (запретить: машинный зал)
└─Пассажиры                  [ALLOW: Lounge] (разрешить: пассажирский зал)
  ├─Джедаи                   <strong>[ALLOW: Cockpit] (разрешить: кабину)</strong>
  │ ├─<strong>Оби-Ван</strong>
  │ └─<strong>Люк</strong>                    [ALLOW: Guns] (разрешить: оружие) 
  ├─R2D2                     [ALLOW: Engines] (разрешить: машинное отделение)
  └─C3PO
</pre>
<h2>Как phpGACL определяет разрешения?</h2>
<p>Когда компьютер судна (с запущенным phpGACL конечно же) проверяет доступ, единственный вопрос, который он может задать себе - “имеет ли человек X доступ к месту Y?” На языке phpGACL это будет выглядеть так: “Может ли ARO X иметь доступ к ACO Y?”
<p>phpGACL определяет, имеет ли определенный человек доступ к определенному месту следуя от вершины дерева к указанному человеку, отмечая по пути явный контроль доступа для того места. Когда мы достигаем нужного человека, получаем конкретный уровень доступа который и является конечным результатом для возвращения. Таким образом мы осуществляем контроль доступа для групп, людей, но имеем возможность расширять эти уровни если нужно.
<p><strong>Пример 1.</strong> Мы спрашиваем: Имеет ли Люк доступ к пассажирскому залу?”
<ul>
<li>устанавливаем правило по умолчанию DENY (запретить);
<li>двигаемся по дереву к Люку: <em>Пассажиры Сокола тысячелетия -> Пассажиры -> Джедаи -> Люк</em>;
<li>начинаем с вершины дерева и двигаемся к Люку: “узел” “Пассажиры Сокола тысячелетия” не говорит ни ничего не об одном из ACO. Оставляем DENY (запрет);
<li>идем дальше, “Пассажиры” - явно говорит, что “Пассажиры” имеют доступ к “пассажирскому залу”. Меняем внутренний результат на “ALLOW” (разрешить);
<li>двигаемся в узел “Джедаи” - он не упоминает “пассажирского зала” вообще – оставляем предыдущий результат;
<li>двигаемся в узел “Люк” - снова нет ничего о “пассажирском зале” - оставляем предыдущий результат;
<li>идти дальше некуда – останавливаемся. Возвращаемый результат будет “ALLOW” (разрешить).
</ul>
<p><strong>Пример 2.</strong> Мы спрашиваем: “Имеет ли Чуви доступ в машинный зал?”
<ul>
<li>устанавливаем правило по умолчанию DENY (запретить);
<li>двигаемся по дереву к Чуви: <em>Пассажиры Сокола тысячелетия -> Команда -> Чуви</em>;
<li>начинаем с вершины дерева и двигаемся к Чуви: “узел” “Пассажиры Сокола тысячелетия” не говорит ни ничего не об одном из ACO. Оставляем DENY (запрет);
<li>идем дальше в узел “Команда” - явно говорит нам - “Команда” имеет доступ к “машинному залу” - меняем внутренний результат на “ALLOW” (разрешить);
<li>двигаемся в узел “Чуви” - есть явное запрещение, которое говорит нам, что доступ в “машинный зал” закрыт. Меняем внутренний результат на “DENY” (запретить);
<li>идти дальше некуда, возвращаем результат “DENY” (запретить).
</ul>
<p>Вы можете видеть, что если группа явно не определяет никаких прав, то она наследует их от родительской группы (предыдущей).Если узел корня (“Пассажиры Сокола тысячелетия”) не определяет никаких разрешений, то он наследует разрешения по умолчанию. В данном случае “DENY ALL” (запретить все).
<p>Это подразумевает несколько интересных моментов об ARO-дереве:
<ul>
<li>ARO-дерево всегда показывает полный список AROs. Поэтому не имеет смысл спрашивать, имеет ли доступ к кабине Джабба, поскольку он не был определен в системе. Однако, phpGACL не проверяет существует ли ARO или ACO перед выполнением проверки. Так, если бы такой вопрос действительно имел бы место, ответ тыл бы “DENY” (запретить);
<li>ARO-дерево может не показывать некоторые определения ACO если они специально не определены в ARO-дереве. Например, Хан определил ACO “ванная комната”. Любой вопрос, подобный этому: “имеет ли Люк доступ в ванную комнату?”, даст отрицательный ответ “DENY” (запрещено), поскольку нигде в ARO-дереве “ванная комната” не упоминается. Имейте ввиду, при исследовании ARO-дерева, некоторые ACO могут быть не видимыми.
</ul>
<p><span class="P1">Обратите внимание:</span> при выяснении через phpGACL вопросов о доступе невозможно использовать Группы как AROs (даже при том, что это может казаться правильным). Например, невозможно ответить на вопрос “Какие пассажиры имеют доступ к оружию?” Полный ответ не Boolean (не Булевый) – DENY / ALLOW (отрицаю / позволяю), а более сложный “Люк и Оби-Ван могут, а R2D2 и С3PO нет”. PhpGACL не предназначен для такого вида ответов.



<h2>Добавление групп</h2>
<p>Хан видит, что ACL начинает выглядеть очень сложно. Есть очень много исключений. Возможно, следует сделать подругому, например, создать новую группу “Инженеры”, которая будет содержать людей, которым позволен доступ в машинное отделение и оружию. Эта группа должна содержать Хана и R2D2, так как они могут восстановить двигатель и оружие. Это позволяет Хану удалить некоторые из “грязных” правил-исключений, это дает определенную выгоду в том, что дает ясное описание:
<pre>
По умолчанию:                [DENY: ALL] (запретить: все)
Пассажиры Сокола тысячилетия
├─Команда                    [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ └─Чуви                     [DENY: Engines] (запретить: машинный зал)
├─Пассажиры                  [ALLOW: Lounge] (разрешить: пассажирский зал)
│ ├─Джедаи                   [ALLOW: Cockpit] (разрешить: кабину)
│ │ ├─Оби-Ван
│ │ └─Люк                    [ALLOW: Guns] (разрешить: оружие) 
│ ├─R2D2
│ └─C3PO
└─Инженеры                   <strong>[ALLOW: Engines, Guns] (разрешить: маш.зал, оружие)</strong>
  ├─<strong>Хан</strong>
  └─<strong>R2D2</strong>
</pre>
<p>Вы можете прочитать это следующим образом: по умолчанию никто никуда не имеет право заходить, команда имеет доступ всюду (кроме Чуви, он не имеет доступа в машинное отделение). Пассажиры имеют доступ только к пассажирскому залу, кроме Джедаев, они имеют доступ к кабине. Люк также имеет доступ к оружию. Инженеры имеют доступ к оружию и машинному отделению.
<p>Наиболее важно, мы можем видеть, что Хан и R2D2 находятся теперь в двух местах ACL. Им нет необходимости быть уникальными. Это делает политики более ясными для читателя: “Ах, Хан и R2D2 имеют доступ к оружию и машинному залу, потому что они инженеры”.
<h2>Добавление людей</h2>
<p>Хан идет в Город облаков, чтобы повидать Ландо и сделать некоторый ремонт. Ландо – предыдущий хозяин Сокола тысячелетия, Хан предполагает отнести его к группе “Команда”. Ландо так же предлагает услуги своего главного инженера Хонтука, для помощи в восстановлении судна, пока оно находится в доке.
<pre>
По умолчанию:                 [DENY: ALL] (запретить: все)
Пассажиры Сокола тысячелетия
├─Команда                     [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ ├─Чуви                      [DENY: Engines] (запретить: машинный зал)
│ └─<strong>Ландо</strong>
├─Пассажиры                   [ALLOW: Lounge] (разрешить: пассажирский зал)
│ ├─Джедаи                    [ALLOW: Cockpit] (разрешить: кабина)
│ │ ├─Оби-Ван
│ │ └─Люк                     [ALLOW: Guns] (разрешить: оружие) 
│ ├─R2D2
│ └─C3PO
└─Инженеры                    [ALLOW: Engines, Guns] (разрешить: маш.зал, оружие)
  ├─Хан
  ├─R2D2
  └─<strong>Хантук</strong>
</pre>
<p>Это дерево показывает как легко можно предоставлять доступ новым людям. Если бы мы использовали первоначальную матричную схему, мы должны были бы установить разрешения для каждого места на корабле и для Ханука и для Ландо. Вместо этого, мы просто добавляем их к нужным группам, в результате чего, их доступ неявно и легко определен.
<h2>Устранение конфликтов</h2>
<p>Что случится, если мы добавим Чуви к списку инженеров?
<pre>
По умолчанию:                 [DENY: ALL] (запретить: все)
Пассажиры Сокола тысячелетия
├─Команда                     [ALLOW: ALL] (разрешить: все)
│ ├─Хан
│ ├─<strong>Чуви</strong>                      [DENY: Engines] (запретить: машинный зал)
│ └─Ландо
├─Пассажиры                   [ALLOW: Lounge] (разрешить: пассажирский зал)
│ ├─Джедаи                    [ALLOW: Cockpit] (разрешить: кабина)
│ │ ├─Оби-Ван
│ │ └─Люк                     [ALLOW: Guns] (разрешить: оружие) 
│ ├─R2D2
│ └─C3PO
└─Инженеры                    [ALLOW: Engines, Guns] (разрешить: маш.зал, оружие)
  ├─Хан
  ├─R2D2
  ├─Ханук
  └─<strong>Чуви</strong>
</pre>
<p>Это делает доступ Чуви к машинному залу неоднозначным, потому что теперь есть две дорожки от корня дерева до Чуви. Если компьютер последует по одной дорожке, то результат будет “DENY” (запрещаю), а если он последует за другой дорожкой, то результат будет “ALLOW” (разрешаю). Так все же, ему запрещен или разрешен доступ?
<p>PhpGACL предупредит вас, если вы сгруппируете ARO таким образом, что доступ ARO к произвольному ACO будет неоднозначным. Но <u>решать</u> конфликт придется <u>вам</u>.
<p>Если при такой неоднозначности спросить компьютер “Имеет ли Чуви доступ к машинному залу?”, то ответ будет “ALLOW” (разрешаю), потому что система вернет вам <u>последний измененный параметр</u> (это политика phpGACL). В этом случае результат “ALLOW”, потому что разрешение “ALLOW: Engines, Guns” (разрешить: машинный зал, оружие), назначенное на группу “Инженеры”, является более свежим, по сравнению с “DENY: Engines” (запретить: машинный зал) группы “Чуви”.
<p>В случае, если ACL содержит неоднозначности, такую ACL называют <strong>непоследовательной</strong>. Непоследовательная ACL может быть очень опасна, вы можете невольно обеспечить доступ несоответствующим людям. Когда phpGACL предупреждает вас о том, что ACL непоследовательна, разрешите конфликт как можно более оперативно, чтобы сразу восстановить последовательность.
<p>Чтобы решить конфликт, вы могли сделать следующее:
<ul>
<li>удалить дерективу “DENY: Engines” у группы “Чуви” в группе “Команда”;
<li>добавить дерективу “DENY: Engines” у группы “Чуви” в группе “Инженеры”;
<li>удалить Чуви из группы “Инженеры”, так как Хан всеравно не считает его достойным инженером.
</ul>
<p>Ха выбрал последний вариант, он удалил Чуви из группы “Инженеры”.
<h2>Обозначение объектов доступа</h2>
<p>phpGACL уникально идентифицирует каждый объект доступа (ARO, AXO, ACO) комбинацией их двух ключевых слов и их типа объекта доступа.
<p>Кортеж “(Тип объекта доступа, Раздел, Значение)” уникально идентифицирует любой объект доступа.
<p>Первый элемент кортежа – тип объекта доступа (ARO, AXO, ACO).
<p>Второй элемент кортежа, названный <strong>Разделом</strong>, является, заданной пользователем, строкой, которая называет общую категорию объекта доступа. Объекты с несколькими доступами могут иметь тоже самое название Раздела. Название раздела должно быть короткое, но описательное (наглядное). Это используется в пользовательском интерфейсе в списках выбора, поэтому логично не делать их слишком длинными.
<p>Разделы сохраняются в ячейке namespace. Разделы не имеют никакого отношения к группам или ARO / AXO-деревьям – они просто механизм, для того чтобы помочь поддерживать большее количество объектов доступа.
<p>Третий элемент кортежа – определенное пользователем, название для объекта доступа, и называется <strong>Значение</strong>. <u>Значение не может содержать пробелы</u> (однако, Раздел – может).
<p><u>Названия Разделов и Значение регистрозависимы.</u>
<p><strong>Примечание:</strong> обычно спрашивают, почему для идентификации объектов доступа используются строки а не целые числа, которые, якобы, кажутся быстрее. Ответ – для ясности. На много более легко понять:
<p>acl_check('system', 'login', 'user', 'john_doe');
чем:
<p>acl_check(10, 21004, 15, 20304);
<p>Так как из контекста часто очевидно к какому типу объекта доступа мы обращаемся, интерфейс для phpGACL (и эта документация) опускает тип объекта доступа и использует формат “Раздел -> Значение” для показа объекта доступа. Однако, программный интерфейс приложения требует “Раздел” объекта доступа и “Значение”, которые должны быть определены в отдельных аргументах функции (тип объекта доступа обычно неявен в описании аргумента).
<p><strong>Пример ACO “Раздел -> Значение”:</strong>
<ul>
<li>“Floors -> 1st” (“Этажи -> 1-й”);
<li>“Floors -> 2nd” (“Этажи -> 2-й”);
<li>“Rooms -> Engines” (“Комнаты -> машинный_зал”).
</ul>
<p><strong>Пример ARO “Раздел -> Значение”:</strong>
<ul>
<li>“People -> John_Smith” (“Люди -> Джон_Смит”);
<li>“People -> Cathy_Jones” (“Люди -> Кэти_Джонс”);
<li>“Hosts -> sandbox.something.com” (“Хосты ->  sandbox.something.com”).
</ul>
<p><strong>Пример использования API:</strong>
<ul>
<li>acl_check(aro_section, aro_value, aco_section, aco_value);
<li>acl_check('People', 'John_Smith', 'Floor', '2nd');
</ul>
<p><strong>Примеры правильного именования:</strong>
<ul>
<li>“ACO - Frob > Flerg”, “ARO – Frob -> Flerg” (Раздел и Значение являются одинаковыми, но это хорошо, поскольку namespaces разные для разных типов объектов доступа);
<li>“ACO – Frob -> Flerg”, “ACO – Frob -> Queegle” (тип объекта доступа и название Раздела одинаковые, это хорошо, поскольку у них разные Значения);
<li>“AXO – Frob Hrung -> Flerg” (Разделы могут содержать пробелы).
</ul>
<p><strong>Пример неправильного именования:</strong>
<ul>
<li>“ACO – Frob -> Flerg”, “ACO – Frob -> Flerg” (тип объекта доступа – Раздел -> Значение должны быть уникальными);
<li>“ACO – Frob -> Flerg Habit” (Значение не может содержать пробелов).
</ul>
<h2>Добавление разделов</h2>
<p>Прежде чем добавить новый объект доступа вы должны создать Раздел. Для добавления нового раздела используйте функцию add_object_section().
<table align="center" cellpadding="5"><tr><td bgcolor="lightgrey">
<pre>
add_object_section(
    string NAME,        Короткое описание того, для чего этот Раздел 
                        используется (пример, 'Levels in building'
                        (“Этажи в здании”)).
    string VALUE,       Название Раздела (пример, 'Floors' (“Этажи”)).
    int ORDER,          Ценность раздела, влияет на то, каким по счету в списке
                        в интерфейсе пользователя появится этот Раздел.
    bool HIDDEN         Показывает, должен ли этот раздел быть виден в
                        пользовательском интерфейсе.
    string GROUP_TYPE); Тип объекта доступа (ACO, ARO, AXO).
</pre>
</td></tr></table>
<p>Хан создал 3 раздела для AROs “Люди”, “Чужие” и “Андроиды” Давайте посмотрим, как будет выглядеть AROs с их полными названиями:
<pre>
Пассажиры Сокола тысячелетия
├─Команда                    [ALLOW: ALL]
│ ├─<strong>"Люди > Хан"</strong>
│ ├─<strong>"Чужие > Чуви"</strong>           [DENY: Engines]
│ └─<strong>"Люди > Ландо"</strong>
├─Пассажиры                  [ALLOW: Lounge]
│ ├─Джедаи                   [ALLOW: Cockpit]
│ │ ├─<strong>"Люди > Оби-Ван"</strong>
│ │ └─<strong>"Люди > Люк"</strong>           [ALLOW: Guns] 
│ ├─<strong>"Андроиды > R2D2"</strong>
│ └─<strong>"Андроиды > C3PO"</strong>
└─Инженеры                   [ALLOW: Engines, Guns]
  ├─<strong>"Люди > Хан"</strong>
  ├─<strong>"Андроиды > R2D2"</strong>
  └─<strong>"Чужие > Хантук"</strong>
</pre>
<p>Разделы – только способ категоризировать объекты доступа, сделать пользовательский интерфейс более пригодным к использованию, а так же сделать функцию acl_check() более читаемой. Они не затрагивают путь phpGACL для определения прав объекта доступа. Также, разделы не могут быть вложенными, то есть вы не можете создать “Мужчин” внутри “Людей”. Вы должны будете создать раздел “Люди мужского пола” или подобный.
<h2>Множество целей</h2>
<p>Возможно, вы будете использовать phpGACL сразу для нескольких целей, например, ограничить пользовательский доступ к страницам, а так же удаленный доступ к страницам вашего сервера. Эти две задачи не связаны.
<p>PhpGACL предлагает реализовать это тремя различными путями:
<ul>
<li>вы можете использовать дополнительные базы данных для хранения этих данных;
<li>вы можете использовать туже самую базу данных но с другими именами таблиц (всеже, эта возможность пока не поддерживается);
<li>вы можете хранить объекты доступа в тех же самых таблицах, и очень тщательно управлять ими, так, чтобы они не вступали в противоречия.
</ul>
<p>Чтобы выбрать первый или второй способ (когда он будет доступен) используйте массив $gacl_options, когда создаете новый класс phpGACL. Это позволит вам определить базу и префикс для таблиц:
<table align="center" cellpadding="5"><tr><td bgcolor="lightgrey">
<pre>
$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);
</pre>
</td></tr></table>
<p>Будьте очень осторожны, если вы выберите третий вариант, поскольку phpGACL ничего не знает об отношениях между вашими задачами, а, следовательно, не сможет контролировать различные бессмысленные директивы политики доступа.
<p>Например, Хан может решить запретить доступ кораблям, которые вступают в контакт с его компьютером, к каким-либо комнатам на корабле. Для этого он может создать “Корабль Люка” как внешний корабль ARO в этом же самом ARO-дереве. В результате чего, станет возможным создать APD (правило автоматической обработки): “Корабли -> Корабль Люка” и назначить ему права “ALLOW (разрешить): “Комнаты -> пассажирский зал”. Согласитесь, это полностью бессмысленно! Чтобы помочь в разрешении таких противоречий, давайте правильное  (информативное) название Разделам, чтобы они четко давали понять, чем на самом деле является объект доступа и для каких задач используются. Это должно быть очевидно для любого администратора, что бессмысленно назначать разрешения кораблям для доступа в какую-либо комнату.
<h2>Объекты расширения доступа (AXO)</h2>
<p>Объекты расширения доступа могут добавлять третье измерение к разрешениям, которые могут формироваться в phpGACL. Мы с вами видели, как phpGACL позволяет комбинировать объекты ARO и ACO (2 измерения) для создания политики доступа. Это очень хорошо для простых разрешений, например:
<p>Люк (ARO) просит разрешение на доступ к Оружию (ACO).
<p>Если это все, чего вы хотите, прекрасно – AXO является полностью дополнительным (то есть может отсутствовать).
<p>Но, поскольку все ACOs являются равными, это мешает справляться с ними если их очень много. Если это так, то мы можем изменить способ, которым мы смотрим на объекты доступа, для более легкого управления ими.
<p>AXOs идентичны AROs во многих отношениях. Есть дерево AXO (отдельное от дерева ARO), со своими собственными Группами и AXOs. Когда вы будете иметь дело с AXO, думайте, что AXO берет на себя старую роль ACO (то есть является “вещами, к которым требуется доступ”), и изменяют представление ACOs с “вещи, к которым требуется доступ” на “действие, которое требуется совершить”.
<p><strong>Посмотрим только на ARO и ACO:</strong>
<ul>
<li>ARO – вещи, просящие доступ;
<li>ACO – вещи, к которым нужен доступ.
</ul>
<p><strong>Посмотрим на ARO, ACO и AXO:</strong>
<ul>
<li>ARO – вещи, которые просят доступ;
<li>ACO – действия, которые требуется совершить
<li>AXO – вещи, к которым нужен доступ.
</ul>
<p><strong>Пример:</strong>
<p>Менеджер сайта пытается управлять доступом к проектам на вебсайте. Дерево ARO состоит из всех пользователей:
<pre>
Вебсайт
├─Администраторы
│ ├─Элис
│ └─Кэрол
└─Пользователи
  ├─Боб
  └─Алан
</pre>
<p>Проекты организованы по принципу используемой операционной системы в Группах AXO:
<pre>
Проекты
├─Linux
│ ├─SpamFilter2
│ └─AutoLinusWorshipper
└─Windows
  ├─PaperclipKiller
  └─PopupStopper
</pre>
<p>Действия, которы могут выполняться над каждым объектом - “Просмотр” и “Редактирование” - это ACOs.
<p>И так, мы хотим, чтобы Боб имел возможность просмотра всех проектов Linux. Это возможно при помощи добавления ADP (автоматической обработки) связки ARO Боба с ACO “Просмотр” и AXO Linux. Теперь мы можем задать вопрос:
<p>“Боб” (ARO) просит действия “Просмотр” (ACO) для проекта “Linux” (AXO).
<p>Обращаю ваше внимание на то, что AXO является дополнительным, если вы не определите AXO, вызывая acl_check(), то ADP (автоматическая обработка) осуществится без учета AXO. Однако, если APD (автоматическая обработка) существует только с AXO, а вы вызовите acl_check() без указания AXO, вы потерпите неудачу.
<p>И так, если вы при вызове acl_check() определяете AXO, то эта функция будет искать в ACL только содержание AXO. Если никакой AXO не определен, только будет рассмотрены только ACL. Это (в теории) дает нам небольшое увеличение скорости работы.
<h1>Инсталляция</h1>
<h2>Базовая настройка</h2>
<ol>
<li>Распакуйте архив дистрибутива в корень или нужную вам папку сайта. Возможно, вы захотите переименовать ее во что-то более подходящее.
<br><img src="manual_html_m48c2db5c.png">
<li>Редактируйте файл phpgacl/gacl.class.php. Установите db_type, db_host, db_user, db_password и db_name, которые вы предполагаете использовать.
<br><img src="manual_html_m6a630ca2.png">
<p>Теперь необходимо отредактировать phpgacl/admin/gacl_admin.inc.php, внеся в него туже самую информацию. Этот файл нужен для административной части скрипта.
<p>Причина, почему необходимо дважды ввести одинаковые данные, заключается в том, что класс gacl.calss.php намного меньше по объему, чем весь программный интерфейс. И нет необходимости тянуть за собой все скрипты, если вам всего лишь необходимо вызвать функцию acl_check().
<li>Создайте базу данных с именем, которое вы задали в db_name.
<li>Запустите http://your_site.net/phpgacl/setup.php. Этот скрипт создаст необходимые таблицы. Не бойтесь сложной информации, скрипт покажет вам только сообщения об успешной работе.
<br><img src="manual_html_7dced6ce.png">
<li>Следуя замечению на картинке (Перевод замечания на картинке: Пожалуйста, создайте директорию <phpGACL root>/admin/templates_c и установите на нее права доступа. Нажмите “Go here!” для начала работы), создайте необходимую директорию. Права доступа должны позволять запись в эту директорию.
<li>Нажмите на “Go here!” и вы перенесетесь сюда: http://your_site.net/admin/acl_admin.php.
</ol>
<h2>Дополнительные настройки</h2>
<p><strong>Если вы уже используете ADOdb</strong> в своих скриптах, то вы можете указать phpGACL использовать уже имеющуюся установку:
<ol>
<li>Отредактируйте phpgacl/gacl.class.php переменную ADODB_DIR, указав в ней путь к установленной библиотеке.
<li>Переименуйте директорию phpgacl/adodb в какую-нибудь другую, например adodb_x и перезапустите phpgacl/admin/acl_admin.php для просмотра изменений.
<li>Удалите директорию adodb, установленную вместе с phpGACL.
</ol>
<p><strong>Если вы уже используете Smarty</strong> в своих скриптах, то вы можете указать phpGACL использовать уже имеющуюся установку:
<ol>
<li>Отредактируйте скрипт phpgacl/admin/gacl_admin.inc.php, установив нем следующие переменные: $smarty_dir и $smarty_compile_dir, чтобы они указывали на каталог, где у вас уже установлен Smarty. Переместите директорию с шаблонами phpGACL в другую директорию (например в ту, которую вы на данный момент уже используете).
<li>Переименуйте папку phpgacl/smarty в другую, например smarty_x. И перезапустите phpgacl/admin/acl_admin.php для просмотра изменений.
<li>Удалите папку smarty инсталляции phpGACL.
</ol>
<p><strong>Как можно переместить phpGACL файлы из моего дерева вебсайта с сохранением связей с деревом для администрирования?</strong>
<ol>
<li>Перейдите в корень вашего вебсайта.
<li>Переместите директорию phpGACL в необходимую вам директорию и создайте симлинк (ссылку) на административную директорию там, где вы хотите его запускать.
<table align="center" cellpadding="5"><tr><td bgcolor="lightgrey">
<pre>
mv phpgacl/ /www/includes_directory
ln -s /www/includes_directory/phpgacl/admin/ gacl
</pre>
</td></tr></table>
<li>Теперь попробуйте запустить phpgacl. Если он не стал работать, то, возможно, ваш сайт не поддерживает симлинки( ссылки).
</ol>
<h1>Использование phpGACL в вашей программе</h1>
<h2>Базовое использование</h2>
<p>Этот пример показывает основной способ использования phpGACL в вашей программе. Он так же показывает использование абстрактного класса для доступа к базам данных ADOdb. Пример иллюстрирует простой способ проверки логина и пароля.
<table align="center" cellpadding="5"><tr><td bgcolor="lightgrey">
<pre>
// Подключаем базовый API
include('phpgacl/gacl.class.php');
$gacl = new gacl();
$username = $db->quote($_POST['username']);
$password = $db->quote(md5($_POST['password']));
$sql = 'SELECT name FROM users WHERE name=';
$sql .= $username.' AND password='.$password;
$row = $db->GetRow($sql);
if($gacl->acl_check('system','login','user',$row['name'])){
  $_SESSION['username'] = $row['name'];
  return true;
}
else
  return false;
</pre>
</td></tr></table>
<p>Вы видете только один вызов acl_check(), что же он означает?
<ul>
<li>Проверяет ARO-объект $row['name'] в ARO-разделе 'user'.
<li>А также ACO-объект 'login' в ACO-разделе 'system'.
</ul>
<h2>Профессиональное использование</h2>
<h2>Использование административного интерфейса</h2>
<p>Отсутствует в оригинальной документации
<h2>Описание API</h2>
<h2>ACL</h2>
<strong>add_acl()</strong>
<p>Добавляет права доступа в лист контроля.
<pre>
add_acl(
    array ACO Ids,
    array ARO_IDs,
    array ARO_GROUP_IDs,
    array AXO_IDs,
    array AXO_GROUP_IDs,
    bool ALLOW,
    bool ENABLED
    [, int ACL_ID])
</pre>
<p>Возвращает:
<p>int ACL_ID, если все прошло хорошо и FALSE, в случае неудачи.

<br><br><br><strong>edit_acl()</strong>
<p>Редактирует права доступа, которые уже установлены в листе контроля.
<pre>
edit_acl (
    array ACO IDs,
    array ARO_IDs,
    array ARO_GROUP_IDs,
    array AXO_IDs,
    array AXO_GROUP_IDs,
    bool ALLOW,
    bool ENABLED
    [, int ACL_ID] )
</pre>
<p>Возвращает:
<p>int ACL_ID если все прошло хорошо и FALSE, в случае неудачи.

<br><br><strong>del_acl()</strong>
<p>Удаляет права доступа, которые уже заданы в листе контроля.
<pre>
del_acl (
    int ACL ID)
</pre>
<p>Возвращает:
<p>TRUE если все прошло успешно, FALSE, в случае неудачи.

<h2>Groups (Группы)</h2>
<strong>get_group_id()</strong>
<p>Возвращает ID группы.
<pre>
get_group_id (
    string GROUP NAME) 	Тип объекта доступа (ARO, ACO, AXO)
</pre>
<p>Возвращает:
<p>int GROUP_ID в случае успеха, FALSE, если неудача.

<br><br><strong>get_group_parent_id()</strong>
<p>Возвращает ID непосредственного родителя группы.
<pre>
get_group_parent_id (
    int GROUP_ID)
</pre>
<p>Возвращает:
<p>int GROUP_PARENT_ID если удача, FALSE – если неудача.

<br><br><strong>add_group()</strong>
<p>Добавляет группу в дерево групп.
<pre>
add_group (
    string NAME
    [, int GROUP_PARENT_ID]
    [, string OBJECT_TYPE])
</pre>
<p>Возвращает:
<p>int GROUP_ID если удача, FALSE если неудача.

<br><br><strong>get_group_objects()</strong>
<p>Возвращает вписок всех объектов отнесенных к группе.
<pre>
get_group_aro (
    int GROUP_ID,
    string GROUP_TYPE)
</pre>
<p>Возвращает:
<p>array SECTION_VALUE, VALUE если удача, FALSE если неудача.

<br><br><strong>add_group_object()</strong>
<p>Соотносит ARO с группой.
<pre>
add_group_aro (
    int GROUP_ID,
    string OBJECT_SECTION_VALUE,
    string OBJECT_VALUE,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int TRUE если удача, FALSE если неудача.

<br><br><strong>del_group_object()</strong>
<p>Удаляет ARO из группы.
<pre>
del_group_aro (
    int GROUP_ID,
    string OBJECT_SECTION_VALUE,
    string OBJECT_VALUE,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int TRUE если удача, FALSE если неудача.

<br><br><strong>edit_group()</strong>
<p>Редактирует группы
<pre>
edit_group (
    int GROUP_ID,
    string NAME,
    int GROUP_PARENT_ID,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int TRUE если удача, FALSE если неудача.

<br><br><strong>del_group()</strong>
<p>Удаляет группу, перераспределяет детей (если есть) или удаляет их.
<pre>
del_group (
    int GROUP_ID,
    bool REPARENT_CHILDREN,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int TRUE если удача, FALSE если неудача.

<h2>Access Objects (ARO/ACO/AXO)</h2>
<p>Этот раздел API управляет объектами доступа, такими как ACO, ARO, AXO.

<br><br><strong>get_object()</strong>
<p>Возвращает массив информации обо всех объектах указанного типа.
<pre>
get_object (
    [string SECTION_VALUE], Необязательный, название Раздела (как фильтр)
    bool RETURN_HIDDEN,	    Возвращать ли объекты с типом “скрытый”
    string GROUP_TYPE) 	    Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>array OBJECT_ID если удача, FALSE если неудача.

<br><br><strong>get_object_data()</strong>
<p>Возвращает массив информации об объекте доступа с конкретным ID.
<pre>
get_object_data (
    int OBJECT_ID,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>array (section_value, value, order_value, name) если удача, FALSE есди неудача.

<br><br><strong>get_object_id()</strong>
<p>Возвращает ID объекта.
<pre>
get_object_id (
    string OBJECT_SECTION_VALUE,
    string OBJECT_VALUE,
    string GROUP_TYPE) Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int OBJECT_ID есди удача, FALSE если неудача.

<br><br><strong>get_object_section_value()</strong>
	Возвращает ID раздела к которому приписан объект.
<pre>
get_object_section_value (
    int OBJECT_ID,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int SECTION_VALUE если удача, FALSE если неудача.

<br><br><strong>add_object()</strong>
<p>Добавляет объект.
<pre>
add_object (
    string SECTION_VALUE,
    string NAME,
    string VALUE,
    int ORDER,
    bool HIDDEN,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>array OBJECT_ID если удача, FALSE если неудача.

<br><br><strong>edit_object()</strong>
<p>Редактирование объекта.
<pre>
edit_object (
    string SECTION_VALUE,
    string NAME,
    string VALUE,
    int ORDER,
    bool HIDDEN,
    string GROUP_TYPE) 	Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>array OBJECT_ID если удача, FALSE если неудача.

<br><br><strong>del_object()</strong>
<p>Удаляет объект.
<pre>
del_object (
    int OBJECT_ID,
    string GROUP_TYPE, 	Тип объекта доступа (ARO, AXO, ACO)
    bool ERASE)
</pre>
<p>Возвращает:
<p>int TRUE если удача, FALSE если неудача.

<h2>Access Object Sections (Разделы объектов доступа)</h2>
<p>Этот раздел API позволяет управлять Разделами, которые являются частью уникального названия объекта доступа (см. “Разделы” для дополнительной информации).

<br><br><strong>get_object_section_section_id()</strong>
<p>Возвращает ID существующего Раздела. Вы должны указать название Раздела или его значение, или оба параметра.
<p>Если вы определите только название, то возможны неоднозначные результаты (так как название не обязано быть уникальным). В этом случае вы получите сообщение об ошибке.
<pre>
get_object_section_section_id (
    string NAME,        Короткое описание того, для чего предназначин Раздел 
                        (например, Этажи в здании”)
    string VALUE,       Название Раздела (например, “Этаж”)
    string GROUP_TYPE)  Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int SECTION_ID если удача, FALSE если неудача.

<br><br><strong>add_object_section()</strong>
<p>Добавляет новый Раздел объектов.
<pre>
add_object_section(
    string NAME,        Короткое описание того, для чего предназначин Раздел 
                        (например, Этажи в здании”)
    string VALUE,       Название Раздела (например, “Этаж”)
    int ORDER,          Ценность Раздела. Учитывается в пользовательском интерфейсе при выводе списка выбора.
    bool HIDDEN,        TRUE – Раздел будет скрыт из списка в пользовательском интерфейсе.
    string GROUP_TYPE)  Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>int SECTION_ID если удачно, FALSE если неудачно.

<br><br><strong>edit_object_section()</strong>
<p>Изменяет атрибуты Раздела. Функция не может изменить тип объекта доступа (для дополнительной информации смотрите add_object_section).
<pre>
edit_object_section (
    int OBJECT_SECTION_ID,  ID раздела (вы можете получить его при помощи
                            функции get_object_section_section_id).
    string NAME,            Новое название Раздела.
    string VALUE,           Новое значение Раздела.
    int ORDER,              Новая ценность раздела.
    bool HIDDEN,            Новый статус раздела (скрыт или нет)
    string GROUP_TYPE)      Тип объекта доступа (ARO, AXO, ACO)
</pre>
<p>Возвращает:
<p>TRUE если удача, FALSE если неудача.

<br><br><strong>del_object_section()</strong>
<p>Удаляет Раздел. Все объекты Раздела также будут удалены!!!
<pre>
del_object_section (
    int SECTION_ID,	ID Раздела
    string GROUP_TYPE,	Тип объекта доступа (ARO, AXO, ACO)
    bool ERASE)	Если TRUE - все объекты Раздела будут удалены.
                Если FALSE, то вы получите сообщение об ошибке в случае,
                если Раздел содержит объекты, Раздел удален не будет,
                если Раздел не содержит объектов, он будет удален.
</pre>
<p>Возвращает:
<p>TRUE если удача, FALSE есди неудача.
<hr>
</body>
</html>