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