Так как на iPad мы не можем редактировать файл hosts (без jailbreaking), как мы можем произвольно перенаправить веб-трафик на другой URL?
Это было бы важно для чего-то вроде разработки веб-сайта, который использует конфигурацию виртуального хоста, где вы хотите перенаправить на машину разработки.
(Это связано с этим вопросом: Могу ли я редактировать файл хоста iPad?)
Способом преодоления этого ограничения iPad является использование прокси-сервера HTTP, такого как Squid, работающего на другом компьютере, где вы можете редактировать файл hosts.
На iPad в разделе "Настройки" → Сеть → Wi-Fi → (ваша сеть). Существует настройка HTTP-прокси, которая может быть настроена на ручной. Введите здесь информацию прокси.
Как только вы настроитесь, вы сможете манипулировать iPad так же, как если бы вы меняли файл hosts.
Я нашел , вам просто нужно изменить настройки Wifi на iPad, чтобы использовать IP-адрес вашей машины разработки в качестве прокси-сервера HTTP (как описано в вышеупомянутая статья):
Таким образом, этого достаточно, чтобы иметь доступ к вашему веб-приложению на iPad, введя URL-адрес виртуального хоста (например, local.mywebapp.com). Это легко и быстро, но в отличие от решения Will Koehler вы, тем не менее, не сможете получить доступ к Интернету с iPad. Но большую часть времени это не проблема, так как вы просто хотите протестировать свое приложение.
Настройте файл hosts на компьютере с прокси-сервером, например, Fiddler или Charles, и настройте iPad для использования этого компьютера в качестве прокси-сервера HTTP.
Вот инструкции, как это сделать с помощью Fiddler: http://conceptdev.blogspot.com/2009/01/monitoring-iphone-web-traffic-with.html
И это для Чарльза: http://www.ravelrumba.com/blog/ipad-http-debugging/
Мне нужно протестировать веб-приложения, которые я разрабатываю на iPad. Я использую Apache на моей машине dev для запуска веб-приложений, поэтому самым простым решением было найти Apache mod_proxy.
Моя машина dev видна в моей домашней сети как sapphire.local.
Веб-приложение, которое я тестирую, размещено на dev-машине на demo.cms.dev(я использую POW).
Чтобы настроить прокси-сервер, я добавил в httpd.conf следующий раздел.
<VirtualHost *:80>
ServerName sapphire.local
ProxyPass / http://demo.cms.dev/
ProxyPassReverse / http://demo.cms.dev/
ProxyPassReverseCookieDomain .cms.dev .sapphire.local
ProxyPreserveHost Off
</VirtualHost>
Это направляет входящие запросы на sapphire.local на demo.cms.dev. Метод работает только для одного приложения за раз. Я думаю, вы можете использовать разные порты для установки дополнительных приложений. Может быть, у кого-то есть лучшее решение?
Если у вас уже есть сервер Apache, на котором вы работаете, вы можете легко использовать его в качестве прямого прокси. Это особенно полезно для сайтов WordPress, которые действительно любят использовать полный абсолютный URL.
Пример Ubuntu ниже:
Первым шагом является редактирование файла /etc/hosts на вашем dev-сервере. Добавьте локальный IP-адрес сервера, указав на свой сайт.
127.0.0.1 dev.mysite.com
Этот файл hosts будет использоваться вашим прокси-сервером Apache, когда он попытается разрешить запросы с вашего iPhone/iPad. Так что теперь настройте часть Apache...
Возможно, вам придется сначала установить некоторые модули.
sudo apt-get install libapache2-mod-proxy-html
sudo a2enmod proxy proxy_http proxy_html
sudo apache2ctl graceful
Затем создайте файл виртуального хоста, например /etc/apache2/sites-available/my-proxy
Listen *:8080
<VirtualHost *:8080>
ProxyRequests On
<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.1.0/24
</Proxy>
</VirtualHost>
Включите vhost и перезапустите Apache:
sudo a2ensite my-proxy
sudo apache2ctl graceful
Затем перейдите в Настройки > Wi-Fi > Сеть > и настройте прокси-сервер "Ручной". Введите IP-адрес вашего сервера Apache и порт. Это!
Блок <Proxy *> гарантирует, что только люди в моей локальной сети могут использовать этот прокси. Строго ограничение доступа важно, если вы используете прямой прокси. Страница ip2cidr будет полезна в этот момент. (В качестве дополнительной меры порт 8080 заблокирован моим брандмауэром.)
Также возможно использовать Weblock - AdBlock для приложения iOS (доступно для $1.99 здесь: https://itunes.apple.com/us/app/weblock/id558818638?mt=8) для создания перенаправления веб-трафика.
Это позволяет перенаправить любой трафик, соответствующий определенному правилу, на указанный IP-адрес. Это будет эмулировать добавление записи на /etc/hosts на устройстве iOS. Если имя хоста, заданное в запросах, обрабатывается IP-адресом, на который вы направляете свой трафик, вы можете использовать его для тестирования частного API или даже трафика с помощью ньюна, отправляемого из других приложений или веб-сайтов. Это, к сожалению, работает только для соединений http/https.
Все это можно сделать только в режиме Wi-Fi (один из ограничений Weblock). Главное преимущество заключается в том, что вы можете легко настроить все с вашего устройства iOS, и нет необходимости возиться с конфигурацией DNS/прокси-сервера.
Вот пример:
macbook-pro-tk:~ kpr$ nc -l -v -v 1234
GET http://www.google.com/ HTTP/1.1
Host: www.google.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Proxy-Connection: keep-alive
PREF=ID=7722bc3c844a7c26:TM=1402073839:LM=1402073839:S=5bSJJsM2p0HgUP7L
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D201 Safari/9537.53
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
Weblock также хорош для выборочного перенаправления некоторого URL-адреса с помощью регулярных выражений. Вы можете перенаправлять запросы только на определенную конечную точку, тогда как все остальные запросы переходят к IP-адресу, возвращаемому из DNS. Это фактически обеспечивает еще более подходящую конфигурацию, которую делает /etc/hosts.
Пример: Если я создам правило перенаправления URL-адресов для htt *://somedomain.com/api/login*, а некоторые IP и порт, я увижу только трафик с этого URL-адреса на этом IP-адресе и порту, а все другой трафик на somedomain.com перейдет непосредственно к IP-адресу, возвращаемому DNS. Обратите внимание, что это будет работать как для /api/login, так и /api/login? Someparam = somevalue благодаря знаку подстановки * в конце правила.
Вы можете настроить внутренний DNS-сервер в своей сети (если его уже не существует) и настроить запись A. Затем убедитесь, что ваш DHCP установлен для возврата указанного DNS-сервера.
Я сделал это, используя squidman на Mac. Легко настроить и использовать.
Я установил его за 5 минут, выполнив эту статью.
Обновление
Другое дело, если вы хотите подключиться к сайтам, работающим на прокси-сервере, в моем случае это мой Mac, вам нужно прокомментировать эту строку в squidman- > Preferences- > Template
# protect web apps running on the proxy host from external users
# http_access deny to_localhost
Вы также можете использовать http://xip.io/, используя инструкции на этой странице, вы можете ввести IP-адрес, и он перенаправит вас на соответствующий локальный ф.
Если у вас есть живой сайт, вы можете использовать для этого:
Вы можете добавить запись A в свою конфигурацию DNS: something.yourdomain.com, которая указывает на ваш локальный IP-адрес, а затем добавьте запись для something.yourdomain.com в ваш файл виртуальных хостов. Перезагрузите Apache, заведите свое устройство iOS в одну и ту же сеть, и вы хорошо пойдете.
Здесь нет способа настройки для тестирования на нескольких устройствах/компьютерах виртуального хоста Mamp Pro. Единственное ограничение - вы можете тестировать только один домен за раз, но для меня это нормально, когда я развиваюсь. Однако очень просто изменить между виртуальными хостами непосредственно в маме.
Im работает mamp pro 2, горный лев. Папка "Мои сайты" содержит отдельные папки домена.
Я обнаружил, что если вы выберете конкретный IP-адрес локального компьютера под виртуальным хостом "ip/port" и перезапустите mamp, этот домен станет доменом по умолчанию при просмотре IP-адреса локальных компьютеров или имени компьютера по сети.
В целях тестирования это отлично работает на всех устройствах в сети, включая iPad. Если вы хотите протестировать другой виртуальный хост, вы можете просто вернуть конфигурацию ip/port в "*", а затем переназначить другой домен на IP-адрес компьютеров и перезапустить.
Преимущество этого простого подхода заключается в том, что вы можете обеспечить доступ к клиентам непосредственно на своих сайтах разработки, когда вы находитесь в одной и той же сети, не имея необходимости проходить какую-либо конфигурацию на своей машине.
Надеюсь, это поможет любому, кто ищет простое решение.
Внутренний DNS-сервер является одним из вариантов, но это слишком громоздко для реализации. Мы попытались установить squid в качестве прокси-сервера, но это также не сработало, потому что оно перенаправляло URL-адрес на новый сервер, и это перенаправление также просматривалось на URL-адрес браузера.
Вещь, которая в конечном итоге работала для нас, заключалась в том, чтобы установить Fiddler на один из серверов и использовать этот сервер в качестве прокси-сервера на ipad. У Fiddler также есть функция для отображения поддоменов на IP-адрес, то есть что-то похожее на/etc/hosts.
Хороший учебник для этого: http://egalo.com/2012/05/29/testing-mac-web-site-using-local-hostname-on-mobile-device/
Другой способ - подключить IPad через локальную точку доступа с моей MAC OS X и установить переадресацию портов на виртуальную машину разработки. Для этого я выполнил следующие шаги:
ssh -NL <IP-of-hotspot-host>:<source-port>:<url-to-local-vm>:80 <user-to-vm><IP-of-hotspot-host>:<source-port>После создания точки доступа есть точка WLAN в
Настройки системы MAC OS X → Сеть → WLAN
На моей разработке VM (Apache2) в /etc/apache2/sites-available/dkr.dev.local Мне пришлось добавить следующее:
<VirtualHost *:80>
...
ServerAlias <IP-of-hotspot-host>
...
</VirtualHost> Я бы попробовал Relay Server (часть Afaria), который может перенаправить мобильный трафик на основе профилей.
Обновление: тремолокий ответ кажется меньше проблем и намного дешевле.
Если вы изучали это и несколько внешних ссылок, вы, возможно, найдете этот ответ:
fooobar.com/questions/55512/...
Речь идет о слабом сервере DNS, называемом dnsmasq. Супер простой, очень мощный и может использоваться в сочетании с внутренними или внешними DNS-серверами.
Намного легче, чем устанавливать squid, возиться с Apache и другими методами, которые потребуют много времени, и рисковать "целостностью" конфигураций, разрабатывать среды, тестовые среды и т.д.
Хорошо стоит рассмотреть.
Я принял это как обычный инструмент для разработки и для нормальной работы в сети.
Ответы здесь верны. Немного больше знаний: они не будут работать с фиксацией сертификата. То, что вы можете сделать, это либо (1) использовать сертификат wildcard домена для поддержки тестирования dev/test/qa. И/или (2) использовать обратный прокси-сервер, такой как Apache, посредством которого вы переходите туда, где Apache направляет запросы в вашей сети. Теперь, когда вы проходите тестирование SSL Pinning, вы мертвы в воде с помощью физических устройств и можете только проверять с помощью симулятора (ios) и эмулятора (android).