Как идентифицировать клиентов https через прокси-соединение - PullRequest
Новая
       35

Как идентифицировать клиентов https через прокси-соединение

0 голосов
/ 07 мая 2019

Мы разработали корпоративное приложение NodeJS, обслуживаемое по протоколу http / 2, и нам необходимо идентифицировать клиентов по их IP-адресу, поскольку серверу необходимо отправлять события клиентам на основе их IP (в основном некоторые данные о телефонных звонках).

Я могу успешно получить IP-адрес клиента через req.connection.remoteAddress, но есть некоторые клиенты, которые могут получить доступ к серверу только через наш прокси-сервер.

Я знаю о заголовке x-forwarded-for, но это не такэто не работает для нас, потому что прокси-серверы не могут изменять заголовки http в ssl-соединениях.

Поэтому я мог бы получить IP со стороны клиента и отправить обратно на сервер, например, во время процесса входа в систему.

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

Изучая ее, я обнаружил только один вариант:получение с сервера, который может сообщить мне IP-адрес, с которого я его получаю.

Конечно, через https я не могу из-за тон прокси.Но я могу легко включить службу http только для обслуживания IP-адреса клиента.

Но потом я обнаружил, что браузеры блокируют http-соединения со страниц, обслуживаемых https, из-за проблемы «смешанного активного содержимого».

Я прочитал об этом и обнаружил, что могу получить " смешанный пассивный контент ", и мне удается загрузить данные об мусоре в виде файла изображения через <img>, но когда я пытаюсь сделать то же самое, используяЭлемент <object> У меня снова возникает проблема с блоком «смешанного активного содержимого», даже в документации MDN говорится, что он считается пассивным .

Есть ли способ прочитать эти данные либо этим (повреждено)) <img> или я что-то упускаю, чтобы сделать элемент <object> действительно пассивным ?

Любая другая идея для достижения нашей цели также будет приветствоваться.

1 Ответ

0 голосов
/ 11 мая 2019

Наконец я нашел решение:

Как я уже сказал, я смог выполнить http-запрос, добавив тег <img>.

Я не смог прочитать загруженные данные независимо от того, было ли это изображение или нет.

... но факт в том, что был сделан запрос и по какому-то URL я могу решить заранее.

Так что все, что мне нужно сделать, это сгенерировать случайный ключ для каждого обслуживаемого экрана входа в систему и:

  • Запомните это вместе с данными вашего сеанса.
  • Вставьте, возможно, скрытый тег <img>, указывающий на какой-либо http-URL, содержащий этот идентификатор.

Как только ваш http-сервер получит запрос на загрузку этого образа, вы сможете прочитать реальный IP-адрес через заголовок x-forwarded-for (доверяя, конечно, вашему прокси-серверу) и решить, какой из них активен. сеанс это принадлежит.

Конечно, вы также должны позаботиться о том, чтобы очистить ключи, независимо от того, используются они или нет, через некоторое время, чтобы избежать утечки памяти или даже для повторного использования с злонамеренными намерениями.

ЗАКЛЮЧИТЕЛЬНОЕ ПРИМЕЧАНИЕ: Единственным недостатком этого подхода является риск того, что когда-нибудь браузеры могут начать блокировать смешанный пассивный контент тоже по умолчанию.

По этой причине я фактически выбрал подход двойной стратегии. То есть: в дополнение к описанной выше методике я также реализовал перенаправитель http, который делает почти то же самое: он перенаправляет все петиции на корневой маршрут ("/") в наше приложение https. Но это происходит с помощью запроса POST, содержащего ключ, который ранее был связан с реальным IP-адресом клиента.

Таким образом, если когда-нибудь первый подход перестанет работать, пользователи в любом случае смогут получить доступ первым через http. ... Что на самом деле то, что мы собираемся сделать. Но первый подход, хотя он и продолжает работать, может избежать проблем, если пользователи решат добавить в закладки страницу изнутри (что приведет к закладке на ее https URL).

...