авторизация на основе ролей graphql

Я новичок в GraphQL и собираюсь создать решение с использованием GraphQL.

Все выглядит круто, но меня беспокоит, как реализовать авторизацию на основе ролей внутри сервера GraphQL (я рассматриваю возможность использования сервера GraphQL.js / apollo)

У меня будет таблица пользователей, содержащая всех пользователей. Внутри таблицы пользователей есть поле ролей, которое содержит роли конкретного пользователя. Запросы и изменения будут предоставляться в зависимости от ролей пользователя.

Как я могу реализовать эту структуру?

БЛАГОДАРНОСТЬ!


person Yue Teng    schedule 11.02.2018    source источник


Ответы (2)


Недавно я реализовал авторизацию на основе ролей с помощью GraphQL Shield, я обнаружил, что использование этого пакета было самый простой способ сделать это. В противном случае вы можете добавить собственные директивы схемы, вот хорошая статья о том, как это сделать: https://dev-blog.apollodata.com/reusable-graphql-schema-directives-131fb3a177d1.

Чтобы настроить GraphQL Shield, необходимо выполнить несколько шагов:

1 - Напишите функцию аутентификации, вот примерный пример, который вы хотите делать гораздо больше, то есть использовать JWT и не передавать идентификатор:

export const isAdmin = async ({ id }) => {
  try {
    const exists = await ctx.db.exists.User({
      id: userId,
      role: 'ADMIN',
    });

    return exists
  } catch (err) {
    console.log(err);
    return false
  }
}

2 - В файл, куда вы экспортируете все свои мутации и запросы, добавьте проверку:

const resolvers = {
 ...your queries and mutations
}

const permissions = {
   Query: {
     myQuery: isAdmin
   }
}

export default shield(resolvers, permissions);

Теперь это будет isAdmin функция каждый раз, когда запрашивается ваш запрос.

Надеюсь, это поможет

person Jamie Halvorson    schedule 08.04.2018

Для разработчиков серверов apollo обычно существует 3 способа реализовать авторизацию в Graphql:

  1. На основе схемы: добавление директивы к типам и полям graphql, которые вы хотите защитить.

  2. На основе промежуточного программного обеспечения: добавление промежуточного программного обеспечения (кода, который запускается до и после выполнения преобразователей graphql). Это подход, используемый graphql-shield и другими библиотеками авторизации, созданными на основе graphql-middleware.

  3. Уровень бизнес-логики: это наиболее примитивный, но детальный подход. По сути, функция, возвращающая данные (например, запрос к базе данных и т. Д.), Будет реализовывать свою собственную проверку разрешений / авторизации.

На основе схемы

  1. С помощью авторизации на основе схемы мы определяем настраиваемые директивы схемы и применяем их везде, где это применимо.

Источник: https://www.apollographql.com/docs/graphql-tools/schema-directives/

//schema.gql

directive @auth(
  requires: Role = ADMIN,
) on OBJECT | FIELD_DEFINITION

enum Role {
  ADMIN
  REVIEWER
  USER
  UNKNOWN
}

type User @auth(requires: USER) {
  name: String
  banned: Boolean @auth(requires: ADMIN)
  canPost: Boolean @auth(requires: REVIEWER)
}

// main.js

class AuthDirective extends SchemaDirectiveVisitor {
  visitObject(type) {
    this.ensureFieldsWrapped(type);
    type._requiredAuthRole = this.args.requires;
  }

  visitFieldDefinition(field, details) {
    this.ensureFieldsWrapped(details.objectType);
    field._requiredAuthRole = this.args.requires;
  }

  ensureFieldsWrapped(objectType) {
    if (objectType._authFieldsWrapped) return;
    objectType._authFieldsWrapped = true;

    const fields = objectType.getFields();

    Object.keys(fields).forEach(fieldName => {
      const field = fields[fieldName];
      const { resolve = defaultFieldResolver } = field;
      field.resolve = async function (...args) {
        // Get the required Role from the field first, falling back
        // to the objectType if no Role is required by the field:
        const requiredRole =
          field._requiredAuthRole ||
          objectType._requiredAuthRole;

        if (! requiredRole) {
          return resolve.apply(this, args);
        }

        const context = args[2];
        const user = await getUser(context.headers.authToken);
        if (! user.hasRole(requiredRole)) {
          throw new Error("not authorized");
        }

        return resolve.apply(this, args);
      };
    });
  }
}

const schema = makeExecutableSchema({
  typeDefs,
  schemaDirectives: {
    auth: AuthDirective,
    authorized: AuthDirective,
    authenticated: AuthDirective
  }
});

На основе промежуточного программного обеспечения

  1. При авторизации на основе промежуточного программного обеспечения большинство библиотек перехватывают выполнение преобразователя. Приведенный ниже пример относится к graphql-shield на apollo-server.

Источник Graphql-shield: https://github.com/maticzav/graphql-shield

Реализация для источника apollo-server: https://github.com/apollographql/apollo-server/pull/1799#issuecomment-456840808

// shield.js

import { shield, rule, and, or } from 'graphql-shield'

const isAdmin = rule()(async (parent, args, ctx, info) => {
  return ctx.user.role === 'admin'
})

const isEditor = rule()(async (parent, args, ctx, info) => {
  return ctx.user.role === 'editor'
})

const isOwner = rule()(async (parent, args, ctx, info) => {
  return ctx.user.items.some(id => id === parent.id)
})

const permissions = shield({
  Query: {
    users: or(isAdmin, isEditor),
  },
  Mutation: {
    createBlogPost: or(isAdmin, and(isOwner, isEditor)),
  },
  User: {
    secret: isOwner,
  },
})

// main.js

const { ApolloServer, makeExecutableSchema } = require('apollo-server');
const { applyMiddleware } = require('graphql-middleware');
const shieldMiddleware = require('shieldMiddleware');

const schema = applyMiddleware(
  makeExecutableSchema({ typeDefs: '...', resolvers: {...} }),
  shieldMiddleware,
);
const server = new ApolloServer({ schema });
app.listen({ port: 4000 }, () => console.log('Ready!'));

Слой бизнес-логики

  1. С помощью авторизации на уровне бизнес-логики мы добавили бы проверки разрешений внутри нашей логики преобразователя. Это наиболее утомительно, потому что нам пришлось бы писать проверки авторизации для каждого резолвера. В приведенной ниже ссылке рекомендуется разместить логику авторизации на уровне бизнес-логики (т. Е. Иногда называемую «Модели», «Логика приложения» или «функция возврата данных»).

Источник: https://graphql.org/learn/authorization/

Вариант 1. Логика аутентификации в резолвере

// resolvers.js

const Query = {
  users: function(root, args, context, info){
    if (context.permissions.view_users) {
      return ctx.db.query(`SELECT * FROM users`)
    }
    throw new Error('Not Authorized to view users')
  }
}

Вариант 2 (рекомендуется): отделение логики авторизации от резолвера

// resolver.js

const Authorize = require('authorization.js')

const Query = {
  users: function(root, args, context, info){
    Authorize.viewUsers(context)
  }
}

// authorization.js

const validatePermission = (requiredPermission, context) => {
  return context.permissions[requiredPermission] === true
}

const Authorize = {
  viewUsers = function(context){
    const requiredPermission = 'ALLOW_VIEW_USERS'

    if (validatePermission(requiredPermission, context)) {
      return context.db.query('SELECT * FROM users')
    }

    throw new Error('Not Authorized to view users')
  },
  viewCars = function(context){
     const requiredPermission = 'ALLOW_VIEW_CARS';

     if (validatePermission(requiredPermission, context)){
       return context.db.query('SELECT * FROM cars')
     }

     throw new Error('Not Authorized to view cars')
  }
}
person David Choy    schedule 11.12.2019
comment
Есть некоторые ограничения для graphql-shield, поскольку он имеет тенденцию блокировать / уничтожать весь запрос, если какое-либо отдельное разрешение не удается. Например, доступная функциональность allow / deny. Он (пока) не смог allowSome. Например, если некоторые разрешения проходят, а некоторые - нет, он не может выборочно разрешить успешное выполнение частей запроса. - person David Choy; 12.12.2019