Авторизация¶

Делегируйте логику авторизации в слой бизнес-логики

Авторизация — это часть бизнес-логики, которая описывает, имеет ли пользователь/сессия/контекст разрешение на выполнение действия или видеть часть информации. Например:

"Только авторы могут видеть свои проекты"

Обеспечение такого поведения должно происходить в слое бизнес-логики. Можно расположить логику авторизации в GraphQL слое в таком виде:

var postType = new GraphQLObjectType({
  name: ‘Post’,
  fields: {
    body: {
      type: GraphQLString,
      resolve: (post, args, context, { rootValue }) => {
        // return the post body only if the user is the post's author
        if (context.user && (context.user.id === post.authorId)) {
          return post.body;
        }
        return null;
      }
    }
  }
});

Обратите внимание на то, что мы определяем "автор владеет постом", проверяя, равняется ли поле AuthorID текущему идентификатору пользователя. Вы можете определить проблему? Мы должны дублировать этот код для каждой точки входа в службу. Тогда, если логика авторизации не синхроннизирована, пользователи могут видеть различные данные в зависимости от API, которое они используют. Хлоп! Мы можем избежать этого, имея единый источник истины для авторизации.

Определение логики авторизации врутри resolver подходит для случая изучения GraphQL или прототипирования. Однако, для кодовой базы в производстве, передайте авторизационную логику в слой бизнес логики. Вот пример:

//Authorization logic lives inside postRepository
var postRepository = require('postRepository');

var postType = new GraphQLObjectType({
  name: ‘Post’,
  fields: {
    body: {
      type: GraphQLString,
      resolve: (post, args, context, { rootValue }) => {
        return postRepository.getBody(context.user, post);
      }
    }
  }
});

В приведенном выше примере, мы видим, что слой бизнес-логики требует, чтобы вызывающий предоставил объект User. Если вы используете GraphQL.js, объект User должен заполнить аргумент "context" или rootValue в четвертом аргументе распознавателя (resolver).

Мы рекомендуем передавать User object вместо непрозрачного token или API ключа к вашей бизнес-логики. Таким образом, мы можем обрабатывать различные проблемы аутентификации и авторизации на различных этапах туннеля обработки запроса.

Авторизация¶

Комментарии