Скрыть имена операций GraphQL ('path') при возникновении ошибок в производственном API

Question

Я создаю приложение React с частным API-интерфейсом graphQL для доступа к нашей базе данных / базе данных. Поскольку наш API по-прежнему закрыт, я не хочу показывать свои конечные точки в Production. К сожалению, когда возникает ошибка graphQL, он возвращает следующие данные на сетевую панель в инструментах разработчика:

{errors: [{,…}], data: {nameOfOperationDisplaysHere: null}
  errors: [{,…}]
    0: {,…}
      message: "Error Message!"
      locations: [{line: 2, column: 3}]
      path: ["nameOfOperationDisplaysHere"]
        0: "nameOfOperationDisplaysHere"
      extensions: {code: "INTERNAL_SERVER_ERROR", exception: {stacktrace: [,…]}}
  data: {nameOfOperationDiplaysHere: null,}

Есть ли способ кодировать / шифровать / скрывать эти имена операций на производстве, чтобы мы не могли не раскрыть имена всех наших конечных точек?

Answer 1

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

Answer 2

Предполагая, что вы используете Apollo Server, вы можете использовать опцию formatResponse , чтобы предоставить функцию для форматирования ответа перед его возвращением сервером. Однако это нецелесообразно, поскольку свойство path требуется GraphQL spe c и по уважительной причине:

Если ошибка может быть связана с конкретным полем в Результат GraphQL должен содержать запись с путем ключа, который подробно описывает путь поля ответа, в котором произошла ошибка. Это позволяет клиентам определить, является ли нулевой результат преднамеренным или вызван ошибкой времени выполнения.

Удаление свойства пути не помешает пользователям узнать подробности о вашей схеме - если пользователь может просмотреть ответ они могут так же легко просмотреть запрос, который сгенерировал ответ. Любые запросы, сделанные вашим клиентом, также будут встроены в ваш код.

В конце концов, даже отключение самоанализа приносит относительно небольшую пользу. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * '' '' '' 'С точки зрения защиты вашего сервиса) гораздо больше, чем авторизация, ограничение скорости и сложности.