Фильтрация данных по роли

[scorpion-ds]

Как лучше фильтровать данные, связанные с текущим пользователем?

- Согласно передаваемым фильтрам, когда фронт сам выбирает какие данные ему нужны, в таком случае бек обеспечивает блокировку только отдельных сущностей, если пользователь не имеет права на доступ к ней. Код на беке проще, на фронте сложней (фронт выбирает согласно роли, какие данные можно запрашивать), один endpouint для списка можно использовать универсально для разных целей.

- Согласно роли другими словами на основе информации о текущем пользователе, бек выводит только, то что он может видеть. На беке код сложней, могут понадобится отдельные endpoint-ы для получения один и тех же сущностей для разных обстоятельств.

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

Проект с GraphQL это делает первый вариант еще более интересным, так как проще обеспечивать изолированность отдельных сущностей и в них обеспечивать проверку на доступ, в случае если доступа нет в списке будет null на месте недоступного объекта, в errors ошибка с пояснение что не так.

 

[WMix]

первое не отменяет второе

 

[scorpion-ds]

первое не отменяет второе

Отменяет как раз, на беке проверяется доступ к объекту, если запрещен то возвращаем null, но при этом генерируем ошибку, при это к примеру count вернет общее количество объектов, включая ошибки, а не только те к которым есть доступ.

 

[WMix]

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

 

[scorpion-ds]

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

В GraphQL другая политика и коды не используются, всегда 200, сообщения об ошибках в разделе error, а запрещенный объект null. В общем, я так понял ты за второй вариант, классический.

 

[WMix]

всегда 200, сообщения об ошибках

мне кажется это заблуждение, GraphQL описывает способ доступа к данным (язык запросов) но не говорит о транспорте.
если тебе необходимо возвращать всегда 200 то это обычный middleware который создаст правильный ответ исходя из полученных данных.
как бы там не было ошибки клиента 4хх и ошибки сервера 5хх тебе необходимо отличать

 

[scorpion-ds]

как бы там не было ошибки клиента 4хх и ошибки сервера 5хх тебе необходимо отличать

На эту тему у нас было обсуждение в команде, мнение архитектора приложения, что GraphQL не зависит от протокола HTTP, потому использовать коды ошибок не имеет смысла. Момент спорный, но я бы отнес это к удобству фронтов, если они довольны, то это не имеет принципиального значения.

 

[weregod]

довольство косым запросом? такое себе

 

[AnrDaemon]

GraphQL не зависит от протокола HTTP

Бред собачий.
Единственное условие - это тело в JSON.

Serving over HTTP | GraphQL

 

[Вурдалак]

Касаемо HTTP-кодов — это дело вкуса и это распространено, насколько я знаю. Мотивация разумная — происходит семантическое смешение разных уровней ошибок. Удален файл на сервере или нет какой-то бизнес-сущности — это вообще разные вещи.

Касаемо вопроса автора — не понял. Говорить «видеть только что что может видеть» касаемо GQL — это странно. В GQL ты сам запрашиваешь явно или неявно нужные тебе поля, а не за тебя решает сервер. И что вообще в данном случае фронт? Запрос идет от ноды к серверу или от клиента к серверу?

В GQL на серверной части есть понятие контекста — объекта, который передается вниз по графу. В нем может быть информация о текущем пользователе и нужные тебе проверки в resolver'ах.

Более того, я как-то не очень понимаю логику ваших разработчиков — ну вот есть какой-то список (не набор полей, а просто один список). Один пользователь должен увидеть одно, а второй — второе (потому что в нашей стране что-то там запретили). Как они на этом уровне что-то по «ролям» будут «фильтровать»?

 

[scorpion-ds]

Более того, я как-то не очень понимаю логику ваших разработчиков — ну вот есть какой-то список (не набор полей, а просто один список). Один пользователь должен увидеть одно, а второй — второе (потому что в нашей стране что-то там запретили). Как они на этом уровне что-то по «ролям» будут «фильтровать»?

Вот я об этом, так просят нас фронт разработчики, они не хотят думать какие им данные нужно получить, они просто хотят обратится к ресурсу и получить, то что им полагается без фильтров.

к примеру, мы разрешаем увидеть пользователей только своей организации, то мы бы могли фильтровать сущности на уровне "выше по графу", то есть если защищенный элемент, скажем "UserEdgeType", то фильтровать мы могли бы в reslovlerUsers (он возвращает UserEdgeType[]) на основании текущего пользователя, сейчас же мы даем для фронта фильтр organizationId, в который они должны передать ИД своего организации, что бы увидеть своих пользователей, без него они увидят список из всех пользователей, но кроме тех что в их организации будут выведены как null и соответствующие ошибки в errors.