Дафна отклоняет все удаленные запросы

У меня есть проект, в котором я использую каналы, и локально все работало хорошо, но когда я развернулся на Heroku, я получал 403 каждый раз, когда пытался подключиться. Сначала я подумал, что проблема в Heroku, поскольку я тестировал его локально и даже локально использовал базу данных и экземпляр redis из Heroku, и все работало.

Но затем, когда я использовал ngrok, чтобы открыть общедоступный туннель к моему локальному хосту, я обнаружил, что результат был таким же, как и в Heroku. Для каждого запроса я получаю 403, и попытка отладки не очень помогает, поскольку цикл обработки событий иногда внезапно берет на себя управление или я получаю ошибку тайм-аута. Настройка точно такая же, как к одному, доступ к которому осуществляется локально, а к другому - удаленно. Вот как я начинаю Дафну: daphne weout.asgi:application --port 8000 --bind 0.0.0.0 -v 3.

Мои версии библиотеки:

  • Django == 2.0.7
  • каналы == 2.2.0
  • каналы-Redis == 2.4.0
  • дафна == 2.3.0

Когда универсальность Дафны установлена ​​на максимум, вот что я получаю, когда пытаюсь подключиться:

Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,489 [asyncio] DEBUG: poll 101.195 ms took 0.023 ms: 1 events
Nov 22 07:16:34 weout-staging app/web.1 10.12.43.130:10299 - - [22/Nov/2019:15:16:33] "WSCONNECTING /api/v1/ws/" - -
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,513 [daphne.http_protocol] DEBUG: Upgraded connection ['10.x.x.x', 10299] to WebSocket
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,648 [asyncio] WARNING: Executing <Task pending coro=<AsyncConsumer.__call__() running at /app/.heroku/python/lib/python3.6/site-packages/channels/consumer.py:59> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7fe01e6979d8>()] created at /app/.heroku/python/lib/python3.6/asyncio/base_events.py:276> created at /app/.heroku/python/lib/python3.6/site-packages/daphne/server.py:209> took 0.131 seconds
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,655 [daphne.server] INFO: failing WebSocket opening handshake ('Access denied')
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,656 [daphne.server] WARNING: dropping connection to peer tcp4:10.12.43.130:10299 with abort=False: Access denied
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,656 [daphne.ws_protocol] DEBUG: WebSocket ['10.x.x.x', 10299] rejected by application
Nov 22 07:16:34 weout-staging app/web.1 10.12.43.130:10299 - - [22/Nov/2019:15:16:33] "WSREJECT /api/v1/ws/" - -
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,660 [aioredis] DEBUG: Parsing Redis URI 'redis://xxxx@xxxxx'
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,660 [aioredis] DEBUG: Creating tcp connection to ('xxx.compute.amazonaws.com', 14059)
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,663 [asyncio] DEBUG: Get address info xxx, type=<SocketKind.SOCK_STREAM: 1>
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,667 [asyncio] DEBUG: Getting address info xxx.compute.amazonaws.com:14059, type=<SocketKind.SOCK_STREAM: 1> took 3.777 ms: [(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('x.x.x.x', 14059))]
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,669 [daphne.ws_protocol] DEBUG: WebSocket closed for ['10.x.x.x', 10299]
Nov 22 07:16:34 weout-staging app/web.1 10.12.43.130:10299 - - [22/Nov/2019:15:16:33] "WSDISCONNECT /api/v1/ws/" - -
Nov 22 07:16:34 weout-staging app/web.1 2019-11-22 15:16:33,671 [asyncio] DEBUG: connect <socket.socket fd=16, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('0.0.0.0', 0)> to ('x.x.x.x', 14059)

Я использую Daphne для обслуживания как обычных представлений Django, так и потребителей веб-сокетов. Для представлений Django все работает хорошо, поэтому проблема возникает только при подключении к потребителям.

Есть ли у кого-нибудь подобная проблема при удаленном доступе к Dapnhe? Сначала я попробовал uvicorn, обслуживаемый с помощью gunicorn, но у них есть ошибка, когда потребитель закрывается во время первоначального подключения. фаза, поэтому я снова переключился на Дафну


person Ken4scholars    schedule 22.11.2019    source источник


Ответы (1)


Оказывается, это был AllowedHostsOriginValidator! Это определенно отняло у меня кучу времени. Кстати, есть идеи, как это промежуточное ПО будет вести себя для запросов от мобильных приложений или других источников без заголовка Origin?

В любом случае я удалил его, и текущая проблема была решена.

person Ken4scholars    schedule 22.11.2019