IA
А кто-нибудь использует хэширование GraphQL-запросов, типа каждый запрос с фронта при сборке отображается в uid, который на сервере маппится в нужный реквест схемы?
Фейсбук)
Size: a a a
2018 July 02
KL
Если я возвращаю в своем написанном middleware JsonResponce, то у меня перестает работать доки и автоподсказки
KL
Как пофиксить?
KL
К сожалению я не могу в middleware сделать raise GraphQLError("error")
Nl
Фейсбук)
Что-то не могу найти ни одного нормального OpenSource-решения — или хотя бы гайда
АР
Что-то не могу найти ни одного нормального OpenSource-решения — или хотя бы гайда
Nl
Это немножко не то, мне кажется, у GraphQL есть проблема с безопасностью в виде возможности создания открытых запросов со стороны пользователя
Назначение каждому запросу с фронта своего хэша, генерируемого с помощью секретного ключа на этапе компиляции, дало бы возможность это избежать
Кажется, FB делает именно так?
Назначение каждому запросу с фронта своего хэша, генерируемого с помощью секретного ключа на этапе компиляции, дало бы возможность это избежать
Кажется, FB делает именно так?
АР
Судя по этой картинке, используется хэш.
АР
(Ох как отобразилось из-за прозрачного фона 😀)
АР
Вопрос лишь в том, что именно вам нужно. В статье речь идёт о хеше с целью ускорения.
p
А кто-нибудь использует хэширование GraphQL-запросов, типа каждый запрос с фронта при сборке отображается в uid, который на сервере маппится в нужный реквест схемы?
это apollo 2 умеет делать
АР
это apollo 2 умеет делать
Я скинул выше как раз ссылку на статью про apollo-server@2. )
Nl
Там следующая картинка показывает, что если хэш на сервере не найден, фронт присылает запрос целиком, и потом он сохраняется в хэш
Nl
Но мне бы хотелось, чтобы фронт мог присывать только некий заданный при компиляции пулл запросов-хешей
АР
Это немножко не то, мне кажется, у GraphQL есть проблема с безопасностью в виде возможности создания открытых запросов со стороны пользователя
Назначение каждому запросу с фронта своего хэша, генерируемого с помощью секретного ключа на этапе компиляции, дало бы возможность это избежать
Кажется, FB делает именно так?
Назначение каждому запросу с фронта своего хэша, генерируемого с помощью секретного ключа на этапе компиляции, дало бы возможность это избежать
Кажется, FB делает именно так?
Вообще, API нужно защищать, чтобы абы кто всё подряд не мог писать и читать. Есть инструменты для этого. Например, GraphQL Shield (https://github.com/maticzav/graphql-shield).
Nl
Вообще, API нужно защищать, чтобы абы кто всё подряд не мог писать и читать. Есть инструменты для этого. Например, GraphQL Shield (https://github.com/maticzav/graphql-shield).
Ну это-то да, у нас пермишены на уровне JWT и микросервисов
Nl
Но мне бы хотелось, чтобы фронт мог присывать только некий заданный при компиляции пулл запросов-хешей
А это бы уберегло сразу и от рекурсивных запросов, и от слишком сложных по нагрузке, и от костылей на ограничение лимита, и вообще радость-счастье-пони
АР
А так любой может через graphql introspection посмотреть что умеет твоё API и составить о нём представление.
Nl
Да, это меня и беспокоит, с хэшами и это бы ушло