Strongloop loopback управляет доступом к данным на основе идентификатора, а не ролей пользователей/acl

Я ищу простой и понятный способ интегрировать петлевую аутентификацию пользователя с моей БД (mysql persistenModels).

Я не могу изменить дизайн базы данных, так как она уже разработана и содержит данные, более того, ответственные лица не хотят ее менять, даже зная, что она может быть лучше.

Извините за качество/ошибки рисунка, но синтезирует текущую структуру в базе данных:

отношение пользователя к инструментам

Я хотел бы проверить модель пользователя Strongloop с таблицей User в БД, а затем каким-то образом сохранить в модели сеанса/cookie/памяти коллекцию table_id, которой он владеет, поскольку многие пользователи могут получить доступ к одному и тому же объекту таблицы.

Это не просто ACL для скрытия конечных точек или предоставления разрешений на обновление/удаление, потому что БД доступна только для чтения. Лучший подход, который я нашел, это следующий: Loopback - Реализация пользовательской аутентификации

Но это не решает проблему, связанную с тем, что если конечная точка Tools опубликована, любой, кто знает tool_id, может получить доступ к данным, поскольку User/Tables/Tools являются PersistenModels, которые получают данные из базы данных.

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

У меня почти нет опыта работы с strongloop, потому что я использую его 3 дня назад, но у меня есть хороший опыт работы с node.js и angular.js.

Любой намек будет оценен.


person Alex B.    schedule 05.01.2017    source источник
comment
Посмотрите на модели Role и RoleMapping, чтобы помочь с этим. Вы можете ограничить аутентифицированных пользователей объектами базы данных, которыми они владеют, используя ACL $owner. Фактическая реализация не очень тривиальна, но это может помочь вам начать с более надежного решения. Вы также можете просто добавить хук beforeRemote, чтобы проверить, что пользователь имеет право собственности, прежде чем отправлять результаты обратно.   -  person notbrain    schedule 06.01.2017
comment
Спасибо за подсказку, я думал об этом вчера, но я пытался реализовать с помощью хука доступа, который не работал. Я попытаюсь сопоставить $owner со списком идентификаторов таблиц и проверять каждый раз, когда вызывается beforeRemote. С вашей подсказкой я думаю, что лучше: сопоставить acl владельца со списком table_id или сопоставить владельца объекта Table со списком user_id, поскольку моей общедоступной конечной точкой является Table, Tools и другие, то есть Project, который использует оба как FK.   -  person Alex B.    schedule 06.01.2017