На следующих страницах будут описаны соответствующие стратегии отладки в различных условиях.Конечно, это может быть неоптимальным решением.
предисловие
Что такое «Ограничение безопасного доменного имени»?
При использовании WeChat JS-SDK в качестве примера каждая официальная учетная запись ограничена максимум тремя безопасными доменными именами, которые должны быть проверены сервером Tencent (это означает, что доменное имя должно быть привязано к серверу, который может быть доступ из Интернета) выше); тогда под этими доменными именами можно использовать только JS-SDK, что является ограничением имени домена безопасности.
Этот тип политики используется относительно широко, что, вероятно, эквивалентно API, предоставляемому третьей стороной, который должен позволять вам настраивать белый список IP-адресов.
На следующем рисунке примерно показан процесс проверки доменного имени JS-SDK, в котором
- WeixinWebview — это браузер в клиенте WeChat;
- BuServer — наш собственный бизнес-сервер;
- WeixinClient — это приложение WeChat;
Предпосылкой следующего процесса являетсяBuServer уже имеет access_token, jsapi_ticket и другую информацию, необходимую для подписи..
Исходя из этого, мы хотим обойти эту политику безопасности, возможно есть два варианта:
- Для нормальной работы используйте фиксированное доменное имя только в качестве теста, заполните его в списке безопасных доменных имен и займите дырку.Конечно, вы можете подать заявку на тестовую учетную запись здесь.», а затем это может быть достигнуто путем решения проблемы проникновения в интранет «ngrok, арахисовой скорлупы и тому подобного»;
- Нестандартные операции, путем изменения разрешения DNS, перезаписи запросов на конкретные ресурсы «или на все ресурсы» в локальную службу разработки;
Нормальная операция
- Через проникновение во внутреннюю сеть ngrok / peanut shell общие инструменты предоставят вам временное доменное имя, а фиксированное доменное имя необходимо оплатить;
- Заполните доменное имя в списке доменных имен безопасности WeChat и поместите файл проверки в веб-контейнер для проверки;
- Выполнив два вышеуказанных шага, вы можете успешно выполнять отладку;
нетрадиционная операция
Как видно из приведенной выше блок-схемы, информация о конфигурации JS-SDK получается путем подписания URL текущей страницы запроса + jsapi_ticket + appid + ...... по определенным правилам, а затем передачи этой конфигурации в Клиент WeChat для проверки законности.
В течение всего процесса проверки мы можем взломать перенаправление запрошенных ресурсов на сервер разработки, чтобы мы могли отлаживать локальный код.
В отношении «перенаправления запрошенных ресурсов на сервер разработки» можно подумать о следующих двух решениях:
- Перехватить запрос и перенаправить его на сервер разработки;
- Используйте разрешение DNS для разрешения безопасных доменных имен на сервер разработки, «широко известный как перехват DNS»;
Решение 1. Пересылка инструмента захвата пакетов
В этой статье мы не будем вдаваться в подробности, вы можете перенаправить указанный запрос через инструменты захвата пакетов, такие как Charles и Fiddler, для достижения цели.
Сценарий 2 Перехват DNS
Сначала вы можете посмотреть на процесс разрешения DNS на следующем рисунке:
Чтобы добиться перехвата DNS, наиболее реалистичным способом является разрешение безопасного доменного имени на IP-адрес локальной среды разработки путем изменения файла hosts на машине разработки.
Перехват HTTP-запросов
Если ваш веб-сайт предоставляет службы HTTP, вам нужно только изменить файл hosts на машине разработки, чтобы указать безопасное доменное имя на службу разработки. Видя, что это почти сделано, вы можете практиковать это сами.
Перехват HTTP-запросов
Однако большинство коммерческих веб-сайтов теперь работают по протоколу HTTPS, поэтому перенаправлять запросы к локальным службам HTTP через перехват DNS непросто.
Если ваше защищенное доменное имя является службой HTTPS, это может вызвать некоторые затруднения. Сначала давайте посмотрим на временную шкалу запроса, такого как сервер HTTPs:
Как видно из приведенного выше рисунка, когда HTTP-запрос инициируется как HTTP-сервер, он будет постоянно перенаправлен на HTTP-запрос, а затем в заголовке ответа будет специальный заголовок «strict-transport-security», который сообщает браузеру, что все запросы в домене будут доступны с использованием HTTP. Поэтому, если в следующий раз будет сделан другой HTTP-запрос, браузер будет внутренне перенаправлен на HTTP-запрос.
Приведенное выше описание запроса HTTPs предназначено для выявления следующих проблем, когда ваше безопасное доменное имя соответствует службе HTTPs:
- После того, как безопасное доменное имя DNS перехватывается на локальную службу HTTP, доступ в браузере по-прежнему является запросом HTTP;
- Исходя из 1, мы подумали об очистке кеша браузера, но инструменты разработчика wechat не могут войти в chrome://net-internals/#hsts для очистки;
Q1: Возьмите Chrome в качестве примера, перейдите на chrome://net-internals/#hsts и очистите политику безопасности.
Q2: В инструменте разработчика WeChat мы не можем войти на эту страницу, что означает, что если имя домена безопасности имеет кеш политики безопасности в инструменте, вы не можете перехватить его на службу HTTP: «Если здесь есть какое-либо решение, пожалуйста, дайте мне знать".
Чтобы решить эту проблему, мы можем только представить окончательное решение и перенаправить запрос через сервер HTTPs, Конкретный процесс выглядит следующим образом:
ProxyServer делает две вещи:
- SSL-сертификат, соответствующий защищенному доменному имени, настроен, и HTTP-запросы поддерживаются;
- Направить запрос под безопасным доменным именем в соответствующую службу разработки;
Если этот ProxyServer существует как общая служба, вам необходимо подумать о том, как проксировать службы разработки, запущенные разными разработчиками.
Сначала мы планировали использовать querystring для указания адреса службы разработки, которую необходимо проксировать, но реальная ситуация такова, что все запросы на странице, которые зависят от этого домена, должны быть переадресованы, поэтому метод querystring не может легко реализовать эту функцию .
Таким образом, это требование в конечном итоге реализуется через файл cookie.Адрес сервера разработки указывается через файл cookie, так что все запросы ресурсов в этом домене будут приносить файл cookie, и может быть реализована настраиваемая переадресация на вышестоящую службу.
Чтобы использовать это решение для отладки WeChat JS-SDK, вам необходимо выполнить следующие два шага:
- Измените файл hosts, чтобы перехватить защищенное доменное имя на прокси-сервис;
- Установите файл cookie, чтобы указать вышестоящую службу, к которой необходимо проксировать;
Таким образом, прокси-служба может существовать как служба общего назначения, и любой разработчик, который обходит ограничения доменного имени безопасности и выполняет некоторую отладку, может использовать эту службу.
FAQ
Вопрос 1. Каковы плюсы и минусы рутинной работы?
Плюсы:
- Есть несколько простых шагов, подходящих для периодической отладки;
Минусы:
- Фиксированные доменные имена стоят денег💰, и если у вас нет фиксированных доменных имен, вам придется их часто менять, но есть только три возможности изменить их в месяц;
- Что делать, если в пуле доменных имен безопасности WeChat нет дыр? . . "Невозможно подать заявку на тестовую учетную запись, но необходимо изменить внутренние интерфейсы, связанные с access_token и jsapi_ticket";
- Недостаточно универсальный, другие трехсторонние логины имеют безопасные настройки доменного имени и не могут использоваться повторно;
Для минуса 1 есть лучшее решение. Его можно комбинировать с перехватом DNS и использовать арахисовую скорлупу для проверки доменного имени при привязке безопасного доменного имени в фоновом режиме WeChat.На самом деле больше нет необходимости использовать арахисовую скорлупу. может изменить хосты и перехватить проверенное доменное имя в локальную службу разработки, поэтому вам не нужно беспокоиться о HTTP или платить за фиксированное доменное имя. Заинтересованные друзья могут попробовать.
Q2. Каковы преимущества нетрадиционных операций?
Pros:
- Дополнительное доменное имя не требуется, а это значит, что нет необходимости изменять конфигурацию имени домена безопасности, а также не нужно менять код сервера;
- Универсальный, есть трехсторонние услуги, похожие на стратегию доменного имени безопасности, чтобы убить;
- Для обычных разработчиков стоимость ежедневной разработки и отладки очень низкая, и никаких специальных разрешений не требуется;
Cons:
- Процесс построения относительно сложен и требует ресурсов сервера;
Q3.Как отлаживать WeChat на реальной машине?
Предлагайте Charles, Mac использует Charles, Win использует fiddler для открытия прокси, если это HTTPs, то также необходимо настроить доверие сертификатов, в этой статье этот шаг повторяться не будет, можете сами погуглить.
Q4. Как подать заявку на тестовый аккаунт?
Tickets.WeChat.QQ.com/debug/CGI-no…
резюме
С точки зрения решения, дополнительная стоимость традиционного решения ниже, но общая стоимость выше, когда несколько разработчиков сотрудничают для разработки официальной учетной записи; нетрадиционное решение больше подходит для нескольких разработчиков, которым необходимо один раз отлаживать WeChat JS-SDK. и для всех.
В ходе всего процесса вы сможете изучить концепцию перехвата DNS, практическое применение и дальнейшее понимание HTTP.