2013-12-16 19 views
6

Próbuję debugować przy użyciu Weinre i skonfigurowałem prosty test w Chrome, aby upewnić się, że wszystko działa. Jednak w narzędziach deweloperskich pojawia się błąd:Jak mogę debugować załadowaną stronę https za pomocą Weinre?

"The page at 'https://myhost/...' was loaded over HTTPS, but ran insecure content from 'http://localhost:8080/target/target-script-min.js': this content should also be loaded over HTTPS. 

widziałem kilka innych odpowiedzi w odniesieniu do debugowania „Cordova” lub „PhoneGap”. Nie używam żadnej z tych rzeczy, a sugerowane odpowiedzi nie mają tu zastosowania. Próbuję debugować tylko prosty HTML/JavaScript.

Nie widzę żadnej wzmianki na stronie internetowej weinre o włączeniu obsługi https (wyraźnie wspomina, że ​​nie używa ona https), i nie mam dużej kontroli nad stroną przeglądarki (ta potrzeba do pracy na różnych przeglądarkach z Androidem, które są notorycznie, w moim przekonaniu, całkowicie nieprzyjazne dla lokalnego debugowania, co jest w rzeczywistości powodem, dla którego próbuję debugować używając Weinre'a), więc nie mam pojęcia, jak postępować. Nie używanie protokołu https nie wchodzi w grę, ponieważ strona przekazuje poufne informacje; używanie weinre przez http jest dopuszczalne, ponieważ tuneluję połączenie przez ssh.

Aktualizacja: Próbowałem również użyć metody Boomarklet: dodałem adres URL bookmarkletu do Chrome Mobile, ale kiedy próbuję przejść do bookmarkletu, wydaje się, że wyładowuję oryginalną stronę: widzę połączenie wykonane, ale kiedy Patrzę na zasoby, wszystko, co widzę, wydaje się być bookmarkletem. Ale jeśli spróbuję uruchomić skryptozakładkę, wpisując nazwę skryptozakładki do momentu pojawienia się kodowanego kodu javascript w autouzupełnianiu, pozostanie on na bieżącej stronie, ale na stronie klienta nie zostaną wyświetlone żadne cele. Zakładam, że jest z tego samego powodu, ponieważ widzę bookmarklet odwołujący się do http://localhost:2000.

Odpowiedz

8

Aby uzyskać ograniczenia przeglądarki, strony weinre mogą być podawane z https zamiast http za pomocą odwrotnego proxy. Jest to trochę brutalne rozwiązanie, ale dodanie następujących wierszy na końcu mojego pliku /etc/httpd.conf wystarczyło do proxy wszystkich żądanych stron z serwera: w moim przypadku żaden z nich nie jest w konflikcie z istniejącymi plikami lub katalogami.

ProxyPass  /target/ http://localhost:8080/target/ 
ProxyPassReverse   /target/ http://localhost:8080/target/ 
ProxyPass  /client/ http://localhost:8080/client/ 
ProxyPassReverse   /client/ http://localhost:8080/client/ 
ProxyPass  /weinre/ http://localhost:8080/weinre/ 
ProxyPassReverse   /weinre/ http://localhost:8080/weinre/ 
ProxyPass  /interfaces/ http://localhost:8080/interfaces/ 
ProxyPassReverse   /interfaces/ http://localhost:8080/interfaces/ 
ProxyPass  /modjewel.js http://localhost:8080/modjewel.js 
ProxyPass  /images/ http://localhost:8080/images/ 
ProxyPassReverse   /images/ http://localhost:8080/images/ 
ProxyPass  /ws/ http://localhost:8080/ws/ 
ProxyPassReverse   /ws/ http://localhost:8080/ws/ 

Konieczne jest również zdefiniowanie window.WeinreServerURL, jak Weinre robi regex na http:/ próbować uzyskać adres URL serwera. To się nie powiedzie, ponieważ serwer to https, a nie http. W moim przypadku, dodałem oświadczenie o następującej postaci do bookmarklet jako pierwsze pismo w funkcji:

window.WeinreServerURL="https://server:port/ 

Mając to na miejscu byłem w stanie wskazać przeglądarkę na https://server:port/client/#anonymous aby otworzyć stronę debugowania, i uruchom skryptozakładkę ze strony pod debugowaniem.

+2

Użyłem ngrok.com aby pozbyć się problemu z Weinre https. Więcej informacji na ten temat opisano w tym artykule: http://www.undefinednull.com/2015/03/17/remote-debugging-localhost-with-weinre/ –

+1

Dzięki 'window.WeinreServerURL' można było uruchomić całość w podkatalogu i https z proxy Nginx! Dzięki! – Aley

3

Świetne pytanie i odpowiedź, @Michael! Miałem to samo pytanie i poszedłem za twoimi wskazówkami, aby uzyskać pracę z moją konfiguracją, która jest z usługami IIS w systemie Windows. Zamieszczam to tutaj jako punkt odniesienia na wypadek, gdyby inni wpadli na ten sam problem.

Z IIS, użyłem następujący proces konfiguracji odwrotnego proxy:

  1. pierwsze, zainstalować rozszerzenie Application Request Routing dla IIS, wraz z jego zależnościami. Dzięki temu konfiguracja odwrotnego proxy jest bardzo łatwa.
  2. Stworzyłem nową stronę internetową, aby uniknąć potencjalnych konfliktów z moją istniejącą witryną. W Menedżerze IIS kliknij prawym przyciskiem myszy na Sites i wybierz Add Web Site.... Nadaj mu nazwę (np. "Weinre") i wskaż go w katalogu tymczasowym. Zmień powiązanie na https i wybierz nieużywany port, na przykład 8005. Możesz również dodać wiązanie http, jeśli chcesz.
  3. Wybierz nowo utworzoną witrynę, a następnie kliknij dwukrotnie moduł URL Rewrite.
  4. Kliknij przycisk Add Rule(s)... w prawym panelu, a następnie użyj szablonu Reverse Proxy.
  5. Upewnij się, że pole Enable SSL Offloading jest zaznaczone, a następnie wprowadź nazwę/port serwera, na którym znajduje się serwer Weinre (np. `127.0.0.1:8080 '). Dodaj regułę, zrestartuj stronę i gotowe!

Teraz, aby go użyć, wystarczy zaktualizować ścieżki do skryptu docelowego do punktu do portu jesteś związany w punkcie 2. I jak Michael zwraca uwagę, musisz również ustawić window.WeinreServerURL jak to możliwe” t automatyczne wykrywanie za pomocą tej konfiguracji.

Happy Debugging!

+0

Witaj Dan, Próbowałem już opisanego podejścia i dodałem samopodpisany certyfikat SSL do serwera IIS. Dodałem stronę o nazwie weinre i dodałem powiązania do http: 80 i https: 443. Dodano również odwrotny serwer proxy z zaznaczonym polem "Enable SSL Offloading". Uruchomiłem ponownie witrynę, a moja konfiguracja działa poprawnie z protokołem http. Problem polega na tym, że nie mogę uruchomić go pod https. Próbowałem ustawić window.WeinreServerURL = "http s: // serwer: port /" (z portem i bez niego) bez powodzenia. Jakieś pomysły? (Witryna, którą chcę przetestować, znajduje się w innej domenie) –

+0

Okazało się, że to z powodu samopodpisanego certyfikatu, powodującego wyjątek bezpieczeństwa w przeglądarce. –

+0

Awesome. Właśnie uratowałeś mi godziny pracy, próbując uzyskać zdalne debugowanie działające przy HTTPS. – asgallant

3

Możesz run weinre on a PaaS, takich jak Heroku lub Bluemix, które zazwyczaj zapewniają zakończenie https, więc aplikacje zasadniczo otrzymują wsparcie https za darmo.

Możesz spróbować wersję https mojego publicznego dostępu do serwera weinre tutaj: https://weinre.mybluemix.net/

+1

Uratowałeś mi życie @Patrick !! –

Powiązane problemy