Как построить взаимодействие админки с данными проекта?

Question

[kustiktm]

Как по хорошему устраивать взаимодействия админки с проектом в плане доступа?
Варики, которые в голове:

1. Подключить админку к бд напрямую без участия основного бека проекта

2. Накрутить доп. эндпоинты по необходимости на основном беке и взаимодействовать через него. Но тогда как беку удостовериться, что это админка? Скипать проверку прав при получении запроса из внутренней сети от определённой тачки? Или мб по другому как-то приконнектить?

Уточню, что для модели и база для юзеров админки и юзеров проекта разные и никак не связаны. Админка не доступна по публичному айпишнику.

Comments

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента. Также обратите внимание на п.3.4

Answer 1

[Александр Маджугин]

Для начала забыть про админку.
Проверять права пользователей на уровне модели данных.
Пилить нужные пользователям интерфейсы.
Профит.

Comments

[kustiktm]

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

[modelair]

Кирилл, а вы - ответа. зачем "админка"? какие задачи? вам предлагают нужное управление прям с интерфейса саймой страницы, наличие элементов в которой определяется наличием прав у юзера

[Александр Маджугин]

Кирилл, с того что админка это вообще не вопрос бэка. Админка должна быть целиком написана на CSS - это вопрос дизайнера и верстальщика, как он зрительно сгруппирует элементы интерфейса для пользователей чтобы они думали что они "в админке". Пока ты мыслишь категорией - это админка, а это не админка - данные в опасности.

[Александр Маджугин]

modelair, да, например можно и так. Примером может быть целая гора CMS которые дают возможность править данные прямо на публичной странице.
А можно и сформировать отдельную "админку" поместив все инструменты которые доступны админам на отдельные роуты.
Если у вас контроль прав на уровне модели данных - вы можете делать как угодно и что угодно. Вам вообще пофиг, потому что у вас правильная архитектура - вы управляете доступом пользователей к данным.

Когда же разработчик мыслит категорией "админки" пилится обычно всякая хрень где пользователи допускаются в определенную зону, а дальше из этой зоны могут делать все что угодно, кем бы они ни были - это дыра в безопасности которая будет в самом фундаменте архитектуры проекта. Я вот об этом.

[kustiktm]

Александр Маджугин, modelair,
Мы видно не правильно друг друга понимаем.
Админка - сокращение "админ-панель".
В моём вопросе фигурирует два бекенда, если вчитаться в суть вопроса: бекенд админ-панели и бекенд проекта, который доступен пользователям.
Админка нужна для управления проектом, доступ в которую предоставляется персоналу.
Мне требуется понять, как правильно спроектировать связь админ-панели с базами данных: через основное API проекта или напрямую в базу данных.

[modelair]

Кирилл, если у вас есть API, то конечно через него.

[Александр Маджугин]

Кирилл, что значит "два бекенда"? Вы погрязните с двумя бекендами в куче дублирующегося кода. Появится масса соблазнов все же где-то его объединить и в итоге это все равно будет один бекенд, или, что еще хуже, будет куча копипасты из одного бэкенда в другой.
Если у вас один набор данных, то и бекенд должен быть один.

[Maksim B]

Звучит очень заманчиво т.к. такой проект потом намного легче развивать и поддерживать.

Однако появляются риски, что из-за одной маленькой ошибки в логике управления правами, доступ к админке получат вообще все пользователи.

[Александр Маджугин]

Maksim B, именно это и пытается сделать ТС - создать такие риски.

[kustiktm]

Maksim B, какое именно решение?)