Полный сравнительный анализ Facebook/GraphQL, APIJSON (2) — контроль разрешений

задняя часть внешний интерфейс GraphQL Facebook

Связанное чтение:

Полный сравнительный анализ Facebook/GraphQL, APIJSON (1) — основные функции

После взрыва Facebook/GraphQL всесторонний сравнительный анализ APIJSON (3) — запрос ассоциации таблиц

 

С момента выпуска APIJSON пользователи сети постоянно сравнивают его с GraphQL Facebook.

Есть даже много людей, которые утверждают, что APIJSON «полностью взорвал».

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

APIJSON «закончил» GraphQL!

 

Слоган APIJSON:

Внутренний интерфейс и автоматизация документов, внешняя (клиентская) настройка возвращаемых данных и структуры JSON!

Введение в APIJSON:

APIJSON — это сетевой транспортный протокол JSON для API.
Предоставляет полностью автоматизированный API для простых добавлений, удалений, изменений, сложных запросов и простых транзакционных операций.
Это может значительно снизить затраты на разработку и связь, упростить процесс разработки и сократить цикл разработки.
Он подходит для малых и средних проектов с разделением клиентской и серверной части, особенно для предпринимательских интернет-проектов и проектов для самостоятельного использования предприятиями.

Через API автоматизации интерфейс может настроить любые данные, любую структуру!
Большинству серверных частей HTTP-запросов больше не нужно писать интерфейсы, не говоря уже о документах!
Внешнему интерфейсу больше не нужно сообщать о проблемах интерфейса или документации с серверной частью! Больше никаких ошибок в документации!
Бэкенду больше не нужно писать новую версию интерфейса и документацию для совместимости со старым интерфейсом! Никогда не надоедает интерфейс бесконечно в любое время и в любом месте!

Функции

Онлайн анализ

  • Автоматически генерировать документацию, понятную, удобочитаемую и всегда актуальную
  • Автоматически генерировать код запроса, поддерживать Android и iOS
  • Автоматическое управление и тестирование вариантов использования интерфейса, обмен в один клик
  • Автоматическая проверка и форматирование JSON, поддержка выделения и расширения

для передней части

  • Нет необходимости отправлять интерфейсы и документы на серверную часть
  • Данные и структура полностью настраиваются, что вы хотите
  • Смотрите запрос, чтобы узнать результат, что вы просите, то и получаете
  • Получите любые данные, любую структуру сразу
  • Может удалять дубликаты данных, экономить трафик и повышать скорость

для бэкенда

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

Демонстрация видео:i.youku.com/apijson

[Следующий Gif-файл выглядит застрявшим, но на самом деле приложение на телефоне работает без сбоев]
  

Домашняя страница проекта:GitHub.com/Томми лимон/…

 

 

Полный сравнительный анализ Facebook/GraphQL, APIJSON (2) — контроль разрешений

 

Автоматизированный контроль доступа(конкретно APIJSON):

GraphQL [не] обеспечивает функциональность контроля доступа, даже вОфициальная документация и исходный кодДаже как добиться учебника почти,

В нем упоминалось только, как [вручную] реализовать контроль разрешений роли [владельца] в вашем [бизнес-коде].

 

 

 

Выделенная строка кода

if (context.user && (context.user.id === post.authorId))

В заднем ручном руководстве написано PostType, руководство плюс функция разрешения, где вместе с такими решениями решениями.

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

 

Следующее любезно напоминает вам не писать его в функции распознавателя определенного типа,

Вместо этого его следует упаковать в PostReponsdom, поместить функцию getBody, а затем реализовать это суждение и вернуть.

Это не только логически понятно, но также может использоваться повторно, когда postType используется в других типах (например, вложенный postType userType). (PS: Это не упоминается в этом документе, я сказал это для этого)

 

 

Но даже если вы потратите время на написание нового класса и новой функции и сделаете эту инкапсуляцию, повторно использовать можно будет только postType.

Другой тип человека, тип дроида, тип запросаПосле ожидания большого количества Типов вам все равно приходится писать их один за другим?

https://github.com/graphql/graphql-js/blob/master/src/__tests__/starWarsSchema.js

 

 

Более того, в современных интернет-приложениях, будь то веб-сайт или мобильное приложение, не только роль [владельца] немного усложняется.

Большинство из них, особенно социальные приложения, содержат роли [Контакты] и [Круг моментов].

Разумеется, все приложения с входом в учетную запись можно разделить на две роли: [вошел в систему] и [не вошел в систему].

 

Поскольку GraphQL не предоставляет функций контроля разрешений, его можно писать только по одному для каждой роли.

Согласно единственному официальному примеру выше, наше суждение для всех ролей должно быть следующим:

Не вошли в:

if (context.user == null || context.user.id == null || context.user.id <= 0) {
  return post.body;
}

return null;

 

Зарегистрировано:

if (context.user && context.user.id && context.user.id > 0) {
  return post.body;
}

return null;

 

Круг друзей:

var userId = context.user == null ? null : context.user.id;
var contactIdList = context.user == null ? null : context.user.contactIdList; //联系人id列表
if ((userId && userId === post.authorId) || (contactIdList && contactIdList.indexOf(post.authorId) >= 0)) {
  return post.body;
}

return null;

 

Контакт:

var contactIdList = context.user == null ? null : context.user.contactIdList; //联系人id列表
if (contactIdList && contactIdList.indexOf(post.authorId) >= 0) {
  return post.body;
}

return null;

 

Владелец:

if (context.user && (context.user.id === post.authorId)) {
  return post.body;
}

return null;

  

 

ТолькоИспользование GraphQL для реализации контроля разрешений роли, соответствующего типу запроса postType, требует написания очень большого количества кода суждения!

Если предположить, что в нашей базе данных 20 таблиц (на самом деле очень легкие приложения имеют именно столько таблиц), и соответственно написано 20 Типов, то 20*5 = 100 суждений! ! !

Нужно как минимум 20*(4 + 4 + 6 + 5 + 4) = 460 строк кода только для определения разрешений роли! ! !

 

 

APJSON обеспечивает автоматический контроль разрешений, который можно разделить на детализацию управления каждой таблицей, каждой строкой записей, каждой ролью и каждой операцией!

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

 

Мы используем APIJSON для работы с таблицей, такой как пользовательская таблица User, и для этого достаточно написать 3 строки кода:

//注册表并添加权限，用默认配置
@MethodAccess
public class User {
  //内容一般仅供表字段说明及Android App开发使用，服务端不用的可不写。
}

//DemoVerifier内添加权限
ACCESS_MAP.put(User.class.getSimpleName(), getAccessMap(User.class.getAnnotation(MethodAccess.class)));

Или вы можете настроить права доступа к POST-запросу:

@MethodAccess(
  POST = {UNKNOWN, ADMIN} //只允许未登录角色和管理员角色新增User，默认配置是 {LOGIN, ADMIN}
)
public class User {}

  

Затем запустите проект сервера, чтобы запросить:

URL-адрес: http://apijson.cn:8080/получить

просить:

{
    "User": {
        "id": 82001
    }
}

вернуть:

{
    "User": {
        "id": 82001,
        "sex": 0,
        "name": "Test",
        "tag": "APIJSON User",
        "head": "http://static.oschina.net/uploads/user/19/39085_50.jpg",
        "contactIdList": [
            82004,
            82021,
            70793
        ],
        "pictureList": [
            "http://common.cnblogs.com/images/icon_weibo_24.png"
        ],
        "date": "2017-02-01 19:21:50.0"
    },
    "code": 200,
    "msg": "success"
}

 

Давайте попробуем еще раз, может ли автоматический контроль разрешений APIJSON оправдать ожидания и можно ли его обойти.

 

Запрос информации об открытии пользователя Пользователь:
/get/{"User":{"id":38710}}

Запрос выполнен успешно:

{
    "User": {
        "id": 38710,
        "sex": 0,
        "name": "TommyLemon",
        "tag": "Android&amp;Java",
        "head": "http://static.oschina.net/uploads/user/1218/2437072_100.jpg?t=1461076033000",
        "contactIdList": [
            82003,
            82005,
            90814,
            82004,
            82009,
            82002,
            82044,
            93793,
            70793
        ],
        "pictureList": [
            "http://static.oschina.net/uploads/user/1218/2437072_100.jpg?t=1461076033000",
            "http://common.cnblogs.com/images/icon_weibo_24.png"
        ],
        "date": "2017-02-01 19:21:50.0"
    },
    "code": 200,
    "msg": "success"
}

  

Запрос информации о конфиденциальности пользователя Конфиденциальность:
/get/{"Privacy":{"id":38710}}

Запрос не выполнен, нет разрешения GET:

{
    "Privacy": {
        "id": 38710
    },
    "code": 401,
    "msg": "Privacy 不允许 UNKNOWN 用户的 GET 请求！"
}

  

Посмотрите на исходный код:

@MethodAccess(
  GET = {},
  GETS = {OWNER, ADMIN}
)
public class Privacy {}

Очевидно, что get не разрешен. Gets можно использовать, но он также должен быть одной из двух ролей OWNER и ADMIN.

 

URL: http://apijson.cn:8080/gets/
просить:

{
    "Privacy": {
        "id": 38710
    },
    "tag": "Privacy"
}

Это все еще не удается, потому что он не вошел в систему, и это НЕИЗВЕСТНЫЙ пользователь, который не вошел в систему. Здесь он автоматически заполняется как ВЛАДЕЛЕЦ:

{
    "Privacy": {
        "id": 38710
    },
    "tag": "Privacy",
    "code": 407,
    "msg": "未登录，请登录后再操作！"
}

 

Так можем ли мы подделать символ, чтобы обмануть APIJSON? Попробуйте:

{
    "Privacy": {
        "id": 38710,
        "@role": "circle"
    },
    "tag": "Privacy"
}

Все та же ошибка: не авторизовался.

{
    "Privacy": {
        "id": 38710,
        "@role": "circle"
    },
    "tag": "Privacy",
    "code": 407,
    "msg": "未登录，请登录后再操作！"
}

  

Что ж, я вхожу в систему и пытаюсь снова, сообщается о новой ошибке:

{
    "Privacy": {
        "id": 38710,
        "@role": "circle"
    },
    "code": 401,
    "msg": "Privacy 不允许 CIRCLE 用户的 GETS 请求！"
}

Зачем? Роль не соответствует ни одной из двух ролей OWNER и ADMIN.


Как насчет перехода на роль ВЛАДЕЛЬЦА?

{
    "Privacy": {
        "id": 38710,
        "@role": "owner"
    },
    "tag": "Privacy"
}

Продолжайте сообщать об ошибках:

{
    "Privacy": {
        "id": 38710,
        "@role": "owner"
    },
    "code": 401,
    "msg": "id = 38710 的 Privacy 不允许 OWNER 用户的 GETS 请求！"
}

  

Как насчет перехода на роль, которой нет у бэкэнда?

{
    "Privacy": {
        "id": 38710,
        "@role": "test"
    },
    "tag": "Privacy"
}

Ошибка, роль не существует:

{
    "Privacy":  {
        "id": 38710 ,
        "@role": "test"
    },
    "code": 406 ,
    "msg": "角色 test 不存在！只能是[UNKNOWN,LOGIN,CONTACT,CIRCLE,OWNER,ADMIN]中的一种！"
}

 

Попробуйте "@role": "admin" еще раз:

{
    "Privacy": {
        "id": 38710,
        "@role": "admin"
    },
    "tag": "Privacy"
}

Все еще получаю ошибку:

{
    "Privacy": {
        "id": 38710,
        "@role": "admin"
    },
    "code": 406,
    "msg": "角色设置错误！不允许在写操作Request中传 Privacy:{ @role:admin } ！"
}

Роль администратора можно задать только внутри сервера, и передавать ее нельзя.

 

Таким образом, в соответствии с конфигурацией разрешений конфиденциальности, внешний интерфейс использует роль ВЛАДЕЛЬЦА только для проверки конфиденциальности текущей учетной записи (id = 82001):

{
    "Privacy": {
        "id": 82001,
        "@role": "owner" //Request表中配置了自动补全，可不写
    },
    "tag": "Privacy"
}

вернет правильный результат:

{
    "Privacy": {
        "id": 82001,
        "certified": 1,
        "phone": 13000082001,
        "balance": 8781.46
    },
    "code": 200,
    "msg": "success"
}

 

Примечание. Все вышеуказанные запросы APIJSON можно найти в http://apijson.orgТест на онлайн-инструменте

 

 

 

Суммировать

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

APJSON обеспечивает автоматический контроль разрешений, который можно разделить на детализацию управления каждой таблицей, каждой строкой записей, каждой ролью и каждой операцией!

И для каждой таблицы нужно написать всего 3 строчки кода, чтобы настроить разрешения на добавление, удаление, изменение и проверку различных ролей! Приведенный выше тестовый примерЭто также показывает, что он не только прост в настройке, но и очень надежен!

 

 

APIJSON, автоматизируйте внутренний интерфейс и документацию, а также настройте данные и структуру JSON, возвращаемые внешним интерфейсом (клиентом)!

Создание не простое, нажмите звездочку в правом верхнем углу, чтобы поддержать его, большое спасибо ^_^

GitHub.com/Томми лимон/…

 

 

Категории