В этой статье рассказывается о разделении интерфейса и сервера, а также о том, как разрабатывать и отлаживать интерфейс в веб-проекте WeChat в локальной среде.
Главная проблема
1. Как настроить среду разработки публичной платформы WeChat
2. Как настроить среду разработки веб-проектов WeChat
3. Как решить междоменную проблему, когда фронтенд и бэкэнд вызывают отдельные интерфейсы разработки
4. Как решить проблему, что сервер WeChat не может получить доступ к локальной тестовой среде
Первое введение о том, как настроить среду разработки платформы общедоступных учетных записей WeChat выше, упоминалось в нескольких предыдущих статьях Shuai Huajun, Вы можете перейти и прочитать его самостоятельно после прочтения этой статьи:
- Получите базовую конфигурацию разработчиков общедоступной платформы WeChat
- Развитие публичной платформы Wechat, динамическое получение и обновление access_token
- Разработка общедоступной платформы Wechat для получения IP-адреса сервера WeChat
- Разработка общедоступной платформы WeChat для получения сообщений и событий и ответа на сообщения
Таким образом, эта статья в основном представляет размышления Шуай Хуацзюня по 2-му, 3-му и 4-му вопросам выше.
Веб-проект WeChat
Веб-разработка Wechat опирается на встроенный браузер Wechat, чтобы предоставить разработчикам широкие возможности (JS-SDK) для вызова клиентского интерфейса Wechat или доступа к системной информации мобильного устройства.Аутентифицированный номер подписки и номер службы могут получать информацию о пользователе, если это необходимо разработчику. чтобы сообщить серверу WeChat, что страница, которую в данный момент посещает пользователь, безопасна, так как же WeChat определяет, что страница, которую в данный момент посещает пользователь, безопасна? Для этого требуется взаимодействие внешнего и внутреннего интерфейса, чтобы выполнить простую проверку для получения авторизации сервера WeChat.
Если пользователь обращается к сторонней веб-странице в клиенте WeChat, официальная учетная запись может получить основную информацию о пользователе через механизм авторизации веб-страницы WeChat, а затем реализовать бизнес-логику.
Об авторизации для получения информации о пользователе можно прочитатьАвторизация на веб-странице WeChat, так как только учетная запись подписки на проверку подлинности WeChat и учетная запись службы проверки подлинности WeChat имеют право на получение информации о пользователе, их можно использовать в фоновом режиме WeChat.Подать заявку на тестовый аккаунт, чтобы поэкспериментировать с процессом авторизации доступа к пользовательской информации на веб-страницах WeChat.
Эксперименты Шуай Хуацзюня с механизмом авторизации веб-страниц прошли гладко, но он столкнулся лишь с небольшой проблемой, которая была решена сразу после внимательного прочтения документа, а именно с пунктом конфигурации о настройке и изменении безопасного доменного имени, упомянутым в документе авторизации WeChat. , иначе или авторизация не удалась, нажмите кнопку Modify справа:
Вы можете изменить доменное имя во всплывающем диалоговом окне:
согласно сИнструкция по разработке веб-проекта WeChat JS-SDK, если вам нужно использовать богатый API-интерфейс встроенного браузера WeChat, вам необходимо внедрить конфигурацию проверки разрешений через интерфейс конфигурации, чтобы убедиться, что страница, к которой в данный момент обращается пользователь, безопасна.
wx.config({
debug: true, // 开启调试模式,调用的所有api的返回值会在客户端alert出来，若要查看传入的参数，可以在pc端打开，参数信息会通过log打出，仅在pc端时才会打印。
appId: '', // 必填，公众号的唯一标识
timestamp: , // 必填，生成签名的时间戳
nonceStr: '', // 必填，生成签名的随机串
signature: '',// 必填，签名
jsApiList: [] // 必填，需要使用的JS接口列表
});
После эксперимента Shuai Huajun информацию о конфигурации можно получить, отправив запрос на серверную часть, а динамическую настройку можно выполнить следующим образом:
getwechatjsconfig(client => {
wx.config({
debug: false,
appId: 'wxa0bb1e90533c6981',
timestamp: client.response.timestamp,
nonceStr: client.response.noncestr,
signature: client.response.signature,
jsApiList: ['chooseImage','previewImage','uploadImage','downloadImage']
})
})
Шуай Хуацзюнь заключает в себеgetwechatjsconfigЭта функция отправит асинхронный запрос на сервер для получения информации о конфигурации. После того, как сервер успешно ответит на запрос Ajax, внешний интерфейс выполнит функцию обратного вызова. Объект экземпляра XHR передается в функцию обратного вызова.responseАтрибут содержит информацию о конфигурации, возвращенную серверной частью. Назначьте эту информацию соответствующим атрибутам, требуемым WeChat, и, наконец, завершите проверку разрешений JS-SDK. В это время пользователь может использовать WeChat JS-SDK на странице. При условии Богатый и практичный интерфейс.
Front-end и back-end раздельная разработка
Для того, чтобы интерфейс имел больше инициативы, более важно оптимизировать весь рабочий процесс интерфейса, повысить эффективность стилей оформления интерфейса, интерактивной логики и спецификаций интерфейса, уменьшить связь интерфейса. и внутреннее содержание работы, а также сделать разделение обязанностей более четким, поэтому крайне важно разделить режим разработки переднего и заднего плана.
Одним из преимуществ разделения фронтенда и бекенда является то, что фронтенду не нужно заботиться о бэкенде, а фронтенд и бекенд пишутся отдельно, нужно только передать документ спецификации интерфейса API, аналогичный протокол передачи, так что данные могут быть видны пользователям как непрерывный поток воды поток между страницей и сервером.
Во-первых, html-документ, хранящийся на сервере, и ресурсы, такие как js\css\image в нем, перетекают из бэкенда во фронтенд, а пользовательский агент (браузер) отображает эти данные в интерфейс, который нравится пользователю, и то каждая операция пользователя на странице меняется.Водоподобные данные передаются на серверную часть через Ajax, и серверная часть обрабатывает входящие данные, а затем отправляет новые данные во внешний интерфейс... Повторяйте это, пока пользователь не перейдет к новому страницы, чтобы начать новый раунд потока данных или до тех пор, пока пользователь не закроет браузер.
Таким образом, первая проблема, которую необходимо решить при разработке разделения интерфейсов и серверов, заключается в том, как обеспечить беспрепятственность передачи данных в процессе передачи интерфейсов и серверов! Это должно упомянуть проблему междоменных барьеров.
Внешний интерфейс создает локальный тестовый сервер (например, http://localhost:8080/) на своем собственном компьютере для выполнения ряда сложных задач, таких как написание стилей макета, написание логики взаимодействия и написание тестовых интерфейсов. сервер http://www.example.com:80/) стал единственным препятствием и столкнулся с междоменными проблемами. Без какой-либо настройки на передней и задней частях Ajax не может отправлять запросы на удаленный сервер. , браузер предупредит фронтенд разработчика!
Кажется, браузер указал мне четкий путь, пока серверная сторона добавляет элемент в соответствующий заголовок ресурса, запрошенного интерфейсом.Access-Control-Allow-OriginПросто настройте:
Серверный скрипт плюс этоAccess-Control-Allow-OriginПосле управления заголовком вы можете получить доступ к тому же адресу API через Ajax в это время, вы можете просмотреть его в консоли, и ответ действительно тот же.Access-Control-Allow-Origin, который используется сервером, чтобы сообщить браузеру, что я разрешаю другим серверам доступ к этому адресу через домены.
На данный момент вход в систему выполнен успешно. Это тест, проведенный Шуай Хуацзюном с его собственным интерфейсом управления статьями. Чтобы получить список всех статей, вы должны сначала войти в систему. Однако я обнаружил, что даже если вход успешно, когда я снова отправляю запрос на сервер, чтобы получить список всех статей, я блокируется Пожалуйста, сначала авторизуйтесь! Эм? ? ? Разве вы только что не вошли в систему? Почему? ? ? Все еще войти? ? ?
Это связано с тем, что, согласно здравому смыслу, когда я успешно вхожу в систему, сервер сохраняет информацию о сеансе текущего пользователя в файле cookie.Уникальная производительность файла cookie гарантирует, что пользователю не нужно снова входить в систему. будет передаваться каждый раз, когда пользователь отправляет запрос на сервер.В заголовке запроса сервер проверяет, вошел ли пользователь в систему с помощью файла cookie. Очевидно, проблема в том, что файл cookie, передаваемый каждый раз, когда пользователь отправляет запрос на сервер, является новым файлом cookie, поэтому, даже если пользователь успешно регистрирует этот запрос, сервер помнит, что до тех пор, пока пользователь, который передает этот файл cookie в следующий раз, Вход выполнен успешно, но проблема в том, что файл cookie, отправленный на сервер по следующему запросу пользователя, не является файлом cookie, который был записан как успешный вход, поэтому для интерфейса, для доступа к которому требуется вход, пользователю всегда будет предлагаться чтобы залогиниться.
Таким образом, проблема, которую необходимо решить сейчас, заключается в том, как обеспечить уникальность файла cookie, содержащегося в заголовке запроса, каждый раз, когда один и тот же пользователь отправляет запрос на сервер, вместо того, чтобы всегда изменяться!
На самом деле это очень просто: интерфейсному интерфейсу достаточно установить следующие атрибуты при инициации Ajax-запроса, и тогда ту же информацию о куках можно будет использовать в последующих запросах:
xhr.withCredentials = true
Внутренний код также нуждается в корректировке.Просто добавьте заголовок запроса, который позволит внешнему интерфейсу переносить учетные данные в соответствующий заголовок сервера.В качестве примера возьмем Express:
res.set('Access-Control-Allow-Credentials', true)
Затем проблема возникает снова.Согласно подсказке предупреждающего сообщения, если учетная информация переносится, тоAccess-Control-Allow-OriginЗначение соответствующего заголовка не может быть подстановочным знаком*.
хорошо, тогда давайте попробуем изменить подстановочный знак, возьмем Express в качестве примера:
res.set('Access-Control-Allow-Origin', 'http://localhost:8080')
После проверки вход в систему проходит успешно, и когда запрос снова отправляется на сервер, передаваемое значение файла cookie точно такое же, как и при успешном входе в систему. сервер не очищает куки, все последующие запросы будут иметь одно и то же значение куки.
Однако Шуай Хуацзюнь считает, что для онлайн-серверовAccess-Control-Allow-Originустановить что-то вродеhttp://localhost:8080Такой адрес локального тестового сервера является очень опасной операцией, потому что, если злонамеренный программист может произвольно отправить запрос с учетными данными на удаленный онлайн-сервер, настроив сервер локально, не будет ли это проблемой для удаленного онлайн-сервера. • Опасно для серверов.
Поэтому при раздельной разработке фронтенда и бэкенда рекомендуется иметь выделенный тестовый сервер, к которому можно получить доступ только по доверенным IP-адресам в локальной сети.Этот тестовый сервер в первую очередь гарантирует, что все Ajax-запросы отправленный нашим собственным интерфейсом, не боясь, что посторонние придут, чтобы создать проблемы, поэтому тестовый сервер, который имитирует онлайн-сервер, может установить соответствующий заголовок, чтобы позволить локальному тестовому серверу отправлять Ajax-запросы с учетными данными.
Внешний локальный сервис проверки WeChat
Любой, кто имеет опыт разработки общедоступной платформы WeChat, знает, что WeChat требует от разработчиков настройки безопасного доменного имени, а URL-адрес под этим безопасным доменным именем должен быть доступен для сервера WeChat, чтобы пройти проверку WeChat и использовать Авторизация общедоступной платформы WeChat или веб-страницы WeChat и проверка JS-SDK.
Подход Shuai Huajun заключается в том, чтобы подать заявку на адрес доменного имени, который поддерживает проникновение во внутреннюю сеть.Магия этого заключается в том, что код в локальном тесте не нужно повторно развертывать на онлайн-сервере для отладки, а сервер WeChat может косвенно получить доступ к локальный сервер.
В технологиях нет ничего слишком продвинутого, вы можете пройти самиnatapp.cnЗарегистрируйтесь, чтобы подать заявку на доменное имя.
После эксперимента по проникновению в интранет проверка общедоступной платформы WeChat, проверка авторизации веб-страницы WeChat и проверка URL-адреса в элементе конфигурации JS-SDK проходят вполне нормально.
Конечно, это только одно из решений, которые необходимо проверить для разработки WeChat. разделение.
Эта статья закончилась.