введение

прежде всего, общий подход для проверка подлинности как вы заявляете, использует подписанный JWT, который содержит идентификатор пользователя, делающего запрос.

теперь давайте посмотрим на различные параметры мы можем использовать при рассмотрении авторизация данного запроса.

• кто делает запрос?

  определяется пользователем id упомянуто выше. Дополнительные сведения о запросчике, например связанные роли пользователей, можно найти в базе данных. Это означает, что мы должны поддерживать User таблица, если мы используем SQL, например, и добавляем новых пользователей в эту таблицу при регистрации.

• какую операцию следует выполнить?

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

• какие поля включены в ответ на запрос / мутацию?

  некоторые поля должны быть доступны только определенным пользователям.

разрешения

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

разрешения на основе ролей

в некоторых приложениях отлично работает ролевой подход. Например, для более простой версии переполнения стека мы могли бы иметь роли EVERYONE, AUTHENTICATED и MODERATOR. Разумным правилом разрешения может быть следующее:

• EVERYONE может читать вопросы / ответы
  • истец: не имеет значения (все)
  • операции: allQuestions, allAnswers запросы
  • поля: text

другие правила (выезд из параметров): * AUTHENTICATED пользователи могут создавать новые вопросы/ответы * MODERATOR пользователи могут создавать новые вопросы/ответы * MODERATOR пользователи могут удалять вопросы/ответы.

теперь, например, если не аутентифицированные запросы поступают, которые запрашивают allQuestions запрос, это нормально как мы находим разрешение, которое позволяет это (первое).

если, с другой стороны, аутентифицированные запросы поступают для пользователя, у которого нет MODERATOR роль и включает в себя deleteQuestion мутация, для этих параметров нет разрешения. Поэтому просьба отклоняется.

график разрешения

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

At Graphcool, мы придумали мощный, но довольно простой подход, который мы называем график разрешения для решения этой проблемы. Давайте сделаем следующие дополнительные параметры доступен при проверке permissions:

• какой узел будет доступен или изменен?

  определяется идентификатором узла

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

в нашем в случае, мы могли бы указать этот запрос разрешения:

query {
  allAnswers(filter:{
      authorId: $userId,
      id: $nodeId
  }) {
    id
  }
}

для данного узла и пользователя, указанного переменными GraphQL $userId и $nodeId, мы используем аргумент запроса filter либо вернуть пустой список, если узел не был создан текущим пользователем, либо что-то ненулевое в противном случае.