TLDR; Коллекция советов по работе с HTTP-прокси. Применяйте прокси на localhost или с мобильного, используя имя своего компьютера или частный ip-адрес из ifconfig (или ipconfig). Цепочка прокси-серверов позволяет использовать возможности всех инструментов одновременно и делает манипуляцию запросами более надежной. Charles Proxy может проверять HTML как часть тестирования.
Рекомендации:
- Используйте прокси для доступа к сервисам на localhost, используя имя своего компьютера или частный ip-адрес из ifconfig (или ipconfig).
- Мобильные устройства могут использовать прокси на вашей основной машине, если вы найдете ее ip-адрес и настроите инструмент для указания прокси на этом ip-адресе.
- Используйте плагин для браузера, например Foxy Proxy Standard, чтобы упростить переключение между прокси.
- Charles Proxy может в фоновом режиме проверять HTML в процессе тестирования.
Работа с Localhost
При работе с локально установленными приложениями или при тестировании приложений, запущенных из локального контейнера docker, возникает проблема, связанная с тем, что они работают на localhost, и нам может понадобится проксировать их.
Общие методы
Вместо localhost:80
Использовать:
- имя машины, например, machinename:80
- ваш частный ip-адрес, например 192.168.1.132:80
Существует ряд частных и недоступных из интернета ip-адресов
Ip-адрес вашей машины можно посмотреть с помощью ifconfig или ipconfig (если вы работаете на Windows).
Использование прокси на локальной машине обычно подразумевает использование этого ip-адреса и должно работать независимо от выбранного прокси.
Когда мне нужно найти ip-адрес на mac, я комбинирую ifconfig с grep, чтобы упростить просмотр результатов:
ifconfig | grep "inet "Charles Proxy
www.charlesproxy.com/documentation/faqs/localhost-traffic-doesnt-appear-in-charles
Charles Proxy поддерживает адрес localhost.charlesproxy.com, поэтому можно добавить порт, на котором он запущен, и трафик появится в Charles.
Fiddler
docs.telerik.com/fiddler/Configure-Fiddler/Tasks/MonitorLocalTraffic
Fiddler поддерживает два специальных адреса, которые можно использовать вместо localhost
Демо-видео
Связывание нескольких HTTP-прокси в цепочку
Я связываю отладочные HTTP-прокси в цепочку.
Таким образом, я могу одновременно использовать их фичи:
- Fiddler Autoresponders
- построение карты сайта с помощью Burp Suite
- множественные брейкпоинты в ZAP
- написание скриптов в ZAP для изменения запросов и ответов.
Я также обнаружил, что это полезно при создании сценариев в прокси-серверах. Иногда по какой-то причине сгенерированный http-запрос после внесения поправок скриптом отправляется в браузер или на сервер не полностью. Но когда я выстраиваю цепочку прокси-серверов, и скрипт, вносящий поправки в запрос или ответ, проходит через другой прокси-сервер, прежде чем попасть к адресату, это, похоже, помогает.
Fiddler
Fiddler работает на системе Windows без каких-либо дополнительных настроек. Все остальные прокси указывают на Fiddler как на downstream-прокси.
Когда Fiddler запущен, проверьте настройки, направив браузер через Fiddler.
Burp Suite
Вкладка Burp Suite Options. Upstream Proxy Servers. Добавьте запись для Fiddler:
- Destination Host: *
- Proxy Host:: localhost
- Proxy Port: 8888
На этом этапе еще раз протестируйте настройки. Не стоит соединять все в цепочку и пытаться понять, где проблема. Запустите браузер через Burp Suite и убедитесь, что трафик проходит через него.
Если вы застряли, используйте вкладку Alerts в Burp Suite для проверки ошибок.
ZAP
Tools Options Connection. Направьте его через Burp Suite
- Порт: 8082 (или тот, к которому вы привязали Burp Suite).
Найдите порт, к которому вы привязали ZAP в Tools Options Local Proxy.
И теперь направьте браузер через этот порт.
Завершение
У вас должно все получиться.
Если нет, просто вернитесь к предыдущему шагу.
Шаг за шагом проверяйте каждую часть пути. Если что-то не работает, то, скорее всего, просто из-за глупой ошибки, связанной с тем, что у вас остались предыдущие настройки от предыдущей сессии.
Не забудьте вернуть все в исходное положение, когда закончите.
На видео курса Technical Web Testing 101 я показываю этот процесс подробнее.
Полезные ссылки:
Мобильные устройства
Настройка просмотра HTTP-трафика с мобильных браузеров не занимает много времени, но есть несколько подводных камней, о которых следует помнить:
- Найти правильный IP-адрес на десктопе.
- Изменить настройки прокси на телефоне.
- Убедиться, что прокси-сервер разрешает внешние подключения.
- Убедиться, что и мобильное устройство и прокси-машина находятся в одной сети.
Я обычно использую:
- Телефон, подключенный к сети Wi-Fi.
- Компьютер с Windows, подключенный к той же сети через проводное соединение (или ноутбук, подключенный через беспроводное соединение).
Для примера возьмем Fiddler в качестве отладочного прокси, на десктопе:
- Запустите Fiddler.
- Убедитесь, что в Fiddler включена настройка «Разрешить подключение удаленных компьютеров» (“Allow remote computers to connect”, через Tools Fiddler Options Connections).
- Запустите командную строку и с помощью команды «ipconfig» откройте текущий список ip-адресов для вашего компьютера.
- Настройте мобильное устройство.
Устройства Android
На мобильном устройстве:
- Откройте Настройки.
- Настройки Wi-Fi.
- Длительным нажатием на пункт «используемая беспроводная сеть» (Wireless Network) откройте настройки подключения (connection settings).
- Выберите «Изменить конфигурацию сети» (Modify Network Config).
- Настройки прокси (Proxy Settings) — Вручную (Manual).
- Измените имя хоста прокси на IP-адрес вашего компьютера.
- Добавьте порт для отладочного прокси, например 8888 для Fiddler.
После этого ваш браузер должен подключиться к прокси.
(Примечание: приведенное выше относится к Android, но принцип работы одинаков и для других операционных систем).
Другие приложения могут использовать прокси другим образом. Возможно, вам потребуется настроить проброс портов с помощью adb для того чтобы они работали через прокси (не спрашивайте меня, как это сделать, погуглите. Я давно этого не делал, поэтому мои воспоминания о том, как я ковырялся в android-е, чтобы заставить его работать, довольно туманны).
На Android: Chrome, Firefox, Dolphin и встроенный браузер работали без проблем. У меня возникли проблемы с подключением Opera, но я даже не стал пытаться выяснить причину.
Попробуйте и посмотрите, что у вас получится.
Это значительно повышает наглядность тестирования при работе через мобильные устройства.
Дополнительные примечания:
- Для Burp Suite в разделе «Proxy Options» измените Proxy Listener to Bind на “All interfaces”.
Как подключить прокси к устройствам iOS
Подключение iOS-устройства к HTTP-прокси происходит примерно так же, как и в случае с Android-устройствами.
Зайдите в настройки iOS:
- В разделе Wi-Fi
- Выберите значок информации (i) рядом с вашей сетью Wi-Fi.
- В нижней части экрана находятся настройки HTTP-прокси.
- Установите для него значение Manual.
- Введите IP-адрес и порт сервера вашего прокси.
Готово.
Теперь HTTP-трафик должен проходить через десктопный прокси-сервер.
iOS хорошо кэширует, поэтому я либо очищаю кэш перед началом тестирования с помощью настроек Safari и пункта «Очистить Cookies и данные», либо использую ссылку «Private» в нижней части Safari перед началом новой сессии.
Я обнаружил, что iOS не любит подключаться к некоторым сетям, поэтому я настроил локальную точку доступа с помощью connectify.me, и это немного облегчило мне жизнь.
Не забудьте отключить прокси-сервер, когда закончите работу.
Простая настройка Chrome и Firefox
Одним из инструментов, который помог мне извлечь больше преимуществ прокси, является плагин для браузера под названием FoxyProxy.
- FoxyProxy Standard — см. getfoxyproxy.org/.
Установив FoxyProxy, я запускаю прокси и выбираю конфигурацию. Большинство прокси по умолчанию используют 8080, поэтому одна конфигурация обычно отвечает большинству моих потребностей.
Без этого мне приходится возиться с настройками браузера или сети, и я никогда бы не стал использовать прокси.
Это также позволяет легко отключить проксирование и вернуться к нормальной работе.
Если вы работаете с HTTP-прокси, я рекомендую установить плагин, который поможет переключаться между ними и отключать их.
Проверка HTML с помощью Charles Proxy
TLDR; Charles Proxy может использовать validator.w3.org и показывать результаты в графическом интерфейсе прокси.
Посмотрев на свой стандартный процесс тестирования для веб и поняв, что он не включает проверку HTML по умолчанию, я решил найти самый простой способ добавить ее в свой процесс. Я вообще считаю, что чем проще я могу добавить что-то в свой процесс, тем больше вероятность того, что я буду это использовать — как и в случае с расширением Foxy Proxy.
Мы все теперь используем Dev Tools по умолчанию
Инструменты Dev Tools (инструменты разработчика) теперь по умолчанию включены в каждый браузер. Раньше нам приходилось загружать плагины и расширения. Но теперь, когда они по умолчанию доступны одним щелчком мыши, у нас нет оправданий.
Но валидация HTML, похоже, отсутствует. Я могу «проверить» производительность страницы в инструментах разработчика Chrome, и считаю проверку использования CSS весьма полезной. Но валидация HTML отсутствует.
Что представляет собой больший технический риск для функциональности ваших продуктов? CSS? Скорость? HTML?
К сожалению, последний, на мой взгляд, вызывает больше проблем на всех устройствах, чем любой другой.
Так что же поможет мне разобраться с основами? И сделать это без излишних усилий.
Я упоминал о validator.w3.org в другой статье. Но это требует работы. Приходится проверять каждую страницу по очереди.
Быстрый поиск в Интернете выявил множество инструментов проверки HTML. Некоторые из них на первый взгляд выглядят вполне неплохо. Но они требуют добавления нового типа инструмента в мой рабочий процесс, что означает, что мне придется изменить способ тестирования, а это в свою очередь значит, что мне придется больше работать, чтобы внедрить его.
Что мне действительно было нужно, так это прокси, проверяющий HTML
- Я поискал плагины Fiddler для проверки HTML, но не нашел ни одного.
- Я не мог вспомнить, чтобы какой-либо из моих прокси предлагал проверку HTML.
Но при поиске в Интернете прокси-серверов, проверяющих HTML, я обнаружил Charles Proxy.
Я уже использовал Charles Proxy, но он, по моему мнению, не отличался какими-либо преимуществами. Видимо, мне не хватало функции проверки HTML.
Но вот она, как на ладони.
Что делает опция Validate в Charles Proxy?
Учитывая урлы, которые вы выделили в «сессии», Charles откроет новую вкладку «валидация» и передаст каждый из этих адресов валидатору w3.org и отформатирует результаты.
Цепочка прокси позволяет воспользоваться этим преимуществом, даже если мы предпочитаем использовать один из других прокси для наблюдения и манипуляций. Я всегда могу добавить Charles в цепочку и использовать его для проверки в процессе работы.
Поскольку Charles является кроссбраузерным, я использую его для тестирования на Windows и Mac.
Резюме
- Изучите свой собственный рабочий процесс.
- Найдите инструменты, которые вписываются в него.
- Узнайте, что умеют делать инструменты, которыми вы уже пользуетесь.
- Попытайтесь плавно добавить автоматическую валидацию в свой рабочий процесс.
- Charles Proxy может использовать валидатор w3.org для проверки HTML.
Признаю, что с этими пунктами у меня возрос объем работы и количество процессов, требующих наблюдения. Но я все же надеюсь, что эти нововведения положительно скажутся на процессе тестирования в общем.
