_ST_78,

что значит сделать некий "скелет прав"? У Вас там просто таблица из двух колонок возможных операций.
А политики, правила, специальные условия?

_ST_78skyANA,

спасибо за вопрос.
Таблиц всего 2 - права и пакеты. Таблица прав предельно простая - ID, name и title. (где колонки ID, title можно не выгружать). Таблица пакетов чуть-чуть посложнее - те же колонки, что и в правах, плюс возможность добавлять колонки отношений. То есть, если к примеру, мы хотим выгрузить все пакеты и чтобы в них через запятую были перечислены имена включенных прав (или ID) - нам нужно просто добавить колонку с нужным типом, нажать "экспортировать" и все будет выгружено.
Насчет политик, спец условий и всего прочего - это уже на плечах разработчика.

Я вижу использование этого конструктора так: чтобы не заморачиваться с написанием управлением групп и тд, можно самому накликать эти группы и права, выгрузить их и записать в свою БД. Далее - к примеру в приложении есть таблица юзеров, их прав и тп. В правах можно указать ID пакета и, к примеру, какие именно права для этого пользователя разрешены и запрещены. И там же можно указывать политики и прочее.

В общем конструктор носит исключительно вспомогательный характер .
Ну хорошо назовём это группами и правами, а не ролями и действиями.

Покажите реальный пример использования.
К примеру есть у нас набор ресурсов (таблицы, индексы, коллекции) и есть набор дествий, что мы можем выполнять с данными ресурсами (читать, добавлять, изменять, смотреть статистику, вычислять контрольную сумму).
И надо нам завести роль read only пользователь, что может только читать, смотреть статистику и вычислять контрольную сумму, и чтобы в итоге это реально работало.

Чем тут Ваш конструктор поможет?

_ST_78,

так, хорошо создали Вы в БД таблицу packages, а дальше?

Покажите вот это: "Далее - к примеру в приложении есть таблица юзеров, их прав и тп. В правах можно указать ID пакета и, к примеру, какие именно права для этого пользователя разрешены и запрещены. И там же можно указывать политики и прочее."

Вообщем хочется увидеть реальный пример использования: чтобы зашёл в приложение и права проверялись.

_ST_78skyANA,

пока работающего примера, к сожалению, нет, но могу объяснить на словах.

Вот мы выгрузили таблицу packages. То, что в ней нет ID - не беда, их можно добавить при выгрузке. Также с правами. Вместо имен прав можно выгружать ID прав, просто я сделал такую выгрузку для наглядности. Создаем табличку users. В ней есть колонка packages, где через запятую, или массивом postgresql, или сериализацией указаны id/name пакетов (кому как удобнее), далее могут быть колонки disabled_rights, enabled_rights. Если обе колонки пустые, значит берем права пакетов без изменений. Если что-то изменено в правах users, то учитываем эти изменения.

Главное, что мы не будем при каждой проверке прав высчитывать права пакетов, они нам уже известны: и включенные, и выключенные.

Также можно пакеты выгружать и без выгрузки всех прав, только одни "прямые" права и все. В таком случае, чтобы узнать все права пакета нужно просто завести колонку с перечислением подпакетов. В общем, выгрузку можно настроить кому-как пожелается.
Извините, микроскопом тоже можно гвозди заколачивать :)

Хотелось бы, чтобы Вы сами для начала применили свой конструктор на практике и показали нам работающее приложение с разграничением прав.

_ST_78skyANA,

спасибо за проявленный интерес)

Просто работающее приложение с правами? Hello world с логином, разлогином и баном подойдет?
Просто логин, разлогин не подойдёт.
Добавьте что-ли таблицу заметок и одному пользователю дайте полные права на работу с ней, другому только на чтение, третьему на чтение и изменение (добавление и удаление запретите).

_ST_78Adx,

полноценную все равно сделать вряд ли получится, так как у всех свои требования (а вот тут надо то, а вот тут хочу это, а вот это лишнее) и тд и тп

Если говорить совсем по простому: само управление правами в самом простом случае состоит из 3 таблиц: права, группы и пользователи. Конструктор берет на себя права и группы: можно создавать различные композиции групп, включать и выключать в них права. И выгружать все это в базу. С таблицей пользователей уже занимается сам разработчик. (включение - выключение персональных прав, добавление - удаление из групп).
ИМХО подход не верен.

Я бы предложил попробовать написать микросервис, куда можно заливать набор ресурсов, действий, ролей, и пользователей, которые выполняют определённые роли.
А не в микросервисе создавать какие-то типа права и группы, а потом их выгружать в целевые приложения.

Тогда приложение тупо спрашивает сервис: а разрешено Васе регистрировать новых пользователей?
А сервис отвечает либо да, либо нет.

_ST_78skyANA,

как понимаю, Вам будет интересно посмотреть на взаимодействие с таблицей на уровне кода приложения?

Насчет микросервиса, думаю, идея заранее обречена на провал. Очень много рисков. Никто не даст гарантии, что доступ к сервису будет постоянным.
Мне интересно посмотреть законченный пример проверки прав пользователя. Сможете его реализовать?

_ST_78, а насчёт обречённости микросервиса...

Я понимаю, что у Вас нет опыта в их написании и Вы судите по ринципу "пальцем в небо", но могли бы просто посмотреть по сторонам и увидеть множество сервисов с доступностью 99,99% времени.

_ST_78skyANA,

Смогу, а насчет пальца в небо и 99 процентов. К примеру в компании есть биллинг, который используется денно и нощно, а проверка прав идет на стороннем сервере. И тут незадача: микросервис упал и остановилась работа биллинга, а клиенты звонят, заявки и прочее нужно заполнять. Да, кстати, микросервис не поднять, ибо доступа к нему нет. И как назло нет дублирующей системы проверки прав. Как быть?
Биллинг с проверкой прав - это что-то новенькое. Пользователи ручками что-ли это делают?

_ST_78,

как часто Вы логинились куда-то, используя OAuth (Open Authorization) и что-то падало? Я вот ни одного такого случая не припоминаю.

_ST_78, кстати, раз уж мы затронули тему биллинга...

Я так полагаю что вы сами себе payment processor, а не используете какой-нибудь PayPal, верно?

A payment processor is a company (often a third party) appointed by a merchant to handle transactions from various channels such as credit cards and debit cards for merchant acquiring banks.