Google App Engine - разрешение запрещено для прокси/туннелирования на сервере разработки

Отказ от ответственности: это не дубликат!

Я использую библиотеку запросов, обезьяна исправлена ​​​​в стандартной среде GAE, и все работает безупречно, за исключением случаев, когда я добавляю дополнительный аргумент proxy к вызову запроса. Этот прокси подразумевает операции туннелирования и сокетов, которые по умолчанию отключены стандартной конфигурацией как среды разработки, так и среды развертывания:

NotImplementedError: HTTP CONNECT Tunnelling is not supported https://pastebin.com/YDsG9we7

Хорошо, поэтому нам нужно включить поддержку реальных сокетов на нашей платформе GAE, поэтому добавьте:

env_variables: GAE_USE_SOCKETS_HTTPLIB : "True"

И даже не выполняя патч для обезьян с инструментальным поясом запросов (вообще не используя urlfetch), мы получаем отказ в разрешении: https://pastebin.com/ifBFKi3K

Обычно это происходит, когда песочница считает, что вы обращаетесь к запрещенному расположению сервера или порту, но прокси-сервер полностью функционален, и знаете что, я тестировал тот же самый код (без каких-либо добавленных/удаленных функциональность из-за разработки или развертывания сервера в качестве текущей среды), и он работает так же, как и ожидалось, при развертывании, без каких-либо ошибок Permission denied, делая запрос полностью успешным (если мы попробуем без включенных сокетов httplib, мы все равно получим эту ошибку Tunnelling is not supported в оба сценария, и это ожидаемое поведение).

Теперь у меня есть рабочее решение для деплоя (а это то, что действительно имеет значение), но мне этого недостаточно, я просто хочу протестировать эти запросы через прокси под моим сервером разработки и в среде, так что я я пытался сделать следующее:

  • let's import our own standard sockets library by applying these: "ImportError: No module named _ssl" with dev_appserver.py from Google App Engine
    • can't monkey patch the sandbox.py file for white-listing _sockets and _ssl etc., no problem, I've hard-patched that directly on disk into the original file
    • замена в памяти сокетов по умолчанию, импорта httplib и т. д. на стандартные питонические
    • ПРОБЛЕМА: ValueError: select only supported on socket objects. https://pastebin.com/gHFM6QiF ; и это каким-то образом ожидается, поскольку ожидаемый объект сокета отличается от ожидаемого из-за стандартного импорта sockets, но собственного select GAE (и удаление выбора из памяти интерпретатора просто вызовет больше проблем или не будет работать вообще), поэтому я хочу заменить модуль select (который является встроенным) стандартным pythonic, как я могу это сделать?

Неважно...

Есть ли какой-то метод, с помощью которого этот кошмар закончится и все еще с использованием стандартной среды? Если он работает на сервере развертывания вообще без каких-либо исправлений, почему бы не работать и с инструментом dev_appserver?

Я просто не хочу делать больше патчей, я просто хочу обойти эту ошибку Permission denied, которая не возникает на сервере удаленного развертывания, используя ту же логику кода, независимо от того, используем ли мы запросы, urfetch, httplib, сокеты и т. д. (просто необходимая вещь для туннелирования прокси).


person Cosmin Poieana    schedule 21.03.2018    source источник
comment
Покопался в вопросе дальше:   -  person Cosmin Poieana    schedule 22.03.2018


Ответы (1)


Покопался в проблеме дальше и, кажется, в этом файле:

platform/google_appengine/google/appengine/api/remote_socket/_remote_socket_stub.py, в котором есть несколько фиктивных пар сокетов (уровень, параметр), найденных в константе _MOCK_SOCKET_OPTIONS, в которой отсутствует пара (1, 3), и это я имею в виду один из продуктов уровней и опций ниже (я думаю, звездочка - это желаемое значение):

Уровни (значение: 1):

  • SOCKET_TCP_NODELAY
  • SOCKET_IP_TOS
  • SOCKET_SOL_SOCKET *
  • SOCKET_SO_DEBUG

Опции (значение: 3):

  • SOCKET_IP_HDRINCL
  • SOCKET_SO_TYPE *
  • SOCKET_TCP_CORK

Таким образом, устанавливая прокси-сервер, я думаю, я запрашиваю группу SOL_SOCKET:SO_TYPE, но как насчет фиктивного значения, которое представляет собой шестнадцатеричную двоичную связанную строку как «00000000» (для проверки активности) и « 01000000" (повторное использование адреса): https://github.com/GoogleCloudPlatform/python-compat-runtime/blob/master/appengine-compat/exported_appengine_sdk/google/appengine/api/remote_socket/_remote_socket_stub.py#L97

Где я могу найти такие значения для отсутствующих пар (1, 3)?


Позднее редактирование:

Я добавил группу «SOL_SOCKET:SO_TYPE=80000000», и теперь она ломается в модуле ssl (который необходимо включить для поддержки https; никаких исправлений не требуется, просто включите его в app.yaml): https://pastebin.com/9KQjdEgL, распознав тип сокета 128, это может быть одной из следующих констант, я думаю:

  • сокет.MSG_EOR
  • сокет.SOMAXCONN
  • socket.TIPC_SRC_DROPPABLE

Позже...

Итак, я понял, что значение 128 является фактическим моим издевательским значением с прямым порядком байтов выше, поэтому я изменил группу на: «SOL_SOCKET: SO_TYPE = 01000000», и это распознает тип сокета socket.SOCK_STREAM, который на самом деле работает только для этой проверки, но затем снова происходит сбой, потому что ssl не понимает пользовательский объект сокета GAE: https://pastebin.com/t2pUuW2V (<google.appengine.api.remote_socket._remote_socket.socket object at 0x7f0cd037f690>). Пробовал это с requests обезьяньим патчем и без него.

Мой вывод

Пользовательский GAE socket не работает полностью с SSL (при туннелировании), а стандартный Python socket не работает с модулем select GAE (я полагаю, без возможности исправления) в отношении песочницы dev_appserver.

Решение: перенести такое же поведение удаленного развертывания в локальную среду разработки.

person Cosmin Poieana    schedule 22.03.2018
comment
Вы можете открыть запрос функции в общедоступной программе Google. - person A.Queue; 30.03.2018