{{tag>доступы Инвентаризация}}
====== Инвентаризация: DEV: Типы доступа ======
Типы доступа используются в ACE для обозначения какой именно доступ объект предоставляется к ресурсу.
Теоретически все просто:
* Есть некие типы, которые привязываются к ACE через many-2-many таблицу
* Также к ACE привязаны объекты, которые получают доступ
* Сами ACE привязываются к ACL, который уже привязан к ресурсу
Из этого можно понять какие ACE, какой доступ получают к каким объектам.
Из необычного:
==== Включения в себя других типов ====
Первоначальная задумка была в том, что могут быть доступы собранные из других доступов, например:
* **Полный** включает в себя
* Чтение
* Запись
Пока не пригодилось вообще никак.
* Можно пока вообще не использовать.
* Можно использовать например только в форме выдачи доступа, где явно выдавать все доступы включенные в комплексный и блокировать их изменение, если они вложены в комплексный.
Если только в форме выдачи прав, тогда
надо сделать контроллер, на который отправляются выставленные права, а тот в ответ высылает, какие должны быть выставлены и какие должны быть заблокированы от снятия (а какие нет)
==== Параметры доступа ====
Потребовалось для учета нестандартных портов, а может быть и стандартных тоже. Пример
Сервис X имеет доступ к сервису Y по протоколу HTTPS по порту 44300 (что не стандартно и должно быть учтено)
Вопросы:
* Значение по умолчанию: если я выбрал протокол HTTPS - то надо по умолчанию заполнять параметр значением TCP 443. Значение по умолчанию этого параметра можно хранить в типе доступа.
* Нужно ли его назвать "сетевые параметры"? У нас есть галочка что доступ подразумевает именно сетевой доступ.
* Наименование параметра: нужно ли его обзывать по разному для разных типов доступа?
нужен контроллер, который в ответ на список выставленных галок возвращает список тех, на которые должны быть созданы поля ввода параметров\
в модели нужно создать поле-массив, куда эти данные нужно будет передать из формы и потом положить в таблицу связей