6

I'm trying to debug using weinre, and have set up a simple test in Chrome to make sure everything is working. However, in the developer tools I get the error:

"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.

I had seen some other answers with regards to debugging "Cordova" or "Phonegap". I am not using either of these things and the answers suggested do not seem to apply here. I am trying to debug simple HTML/Javascript only.

I don't see any mention on the weinre web page of enabling https support (it explicitly mentions that it doesn't use https), and I don't have a lot of control over the browser side (this needs to work on various android browsers which are notorious, in my mind anyway, at being totally unfriendly towards local debugging, which is in fact the reason I am trying to debug using weinre), so I am at a loss as to how to proceed. Not using https is out of the question, as the page passes sensitive information; using weinre over http is acceptable because I am tunnelling the connection over ssh.

Update: I have also tried using the boomarklet method: I added the bookmarklet URL to Chrome Mobile, but when I try navigating to the bookmarklet, it appears to unload the original page: I can see the connection made, but when I look at the resources, all I see is what appears to be the bookmarklet. But if I try to run the bookmarklet by typing the name of the bookmarklet until the starred javascript code appears in autocomplete, it stays on the current page, but no targets show up in the client page. I assume it is for the same reason, as I see the bookmarklet referencing http://localhost:2000.

Michael
  • 9,060
  • 14
  • 61
  • 123

3 Answers3

8

To get by browser restrictions, weinre pages can be served from https instead of http using a reverse proxy. This is somewhat of a brute-force solution, but adding the following lines to the end of my /etc/httpd.conf file were sufficient to proxy all the pages weinre requests from the server: in my case, none of these conflict with existing files or directories.

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/

It is also necessary to define window.WeinreServerURL, as Weinre does a regex on http:/ to try to get the URL of the server. This will fail since the server is https, not http. In my case, I added a statement of the following form to the bookmarklet as the first statement in the function:

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

With this in place I was able to point my browser at https://server:port/client/#anonymous to bring up the debug page, and run the bookmarklet from the page under debug.

Michael
  • 9,060
  • 14
  • 61
  • 123
  • 2
    I have used ngrok.com to get rid of the https issue with Weinre. More about it described in this article http://www.undefinednull.com/2015/03/17/remote-debugging-localhost-with-weinre/ – Shidhin Cr Mar 20 '15 at 03:27
  • 1
    With `window.WeinreServerURL` it was possible to run the whole thing under a subdirectory and https with Nginx proxy! Thanks! – Aley Jul 29 '15 at 12:30
3

Great question and answer, @Michael! I had the same question, and followed your guidance to get things working with my setup, which is with IIS on Windows. I'm posting this here as a reference in case others run into the same issue.

With IIS, I used the following process to setup the reverse proxy:

  1. First off, install the Application Request Routing extension for IIS, along with its dependencies. This makes it super-easy to setup a reverse proxy.
  2. I created a new website for this, to avoid potential conflicts with my existing site. In IIS Manager, right click on Sites and choose Add Web Site.... Give it a name (e.g. 'weinre') and point it at a temporary directory. Change the binding to https, and choose an unused port, such as 8005. You can also add an http binding if you'd like.
  3. Select the newly created site, then double click on the URL Rewrite module.
  4. Click Add Rule(s)... in the right panel, then use the Reverse Proxy template.
  5. Ensure the Enable SSL Offloading box is checked, and then enter the server name/port where the weinre server is located (e.g. `127.0.0.1:8080'). Add the rule, restart the website, and you're done!

Now, to use it, simply update the paths to the target script to point to the port you bound in step 2. And, as Michael points out, you'll also need to set window.WeinreServerURL as it can't auto-detect with this setup.

Happy Debugging!

Dan
  • 1,313
  • 1
  • 14
  • 21
  • Hi Dan, I have tried the approach you have described, and have added self-signed SSL certificate to the IIS server. I have added a site named weinre, and have added bindings to http:80 and https:443. Also added the reverse proxy with the "Enable SSL Offloading" box checked. I have restarted the site, and my setup works fine with http protocol. The problem is that I cannot make it to work under https. I tried setting window.WeinreServerURL="http s://server:port/" (with and without port) to no luck. Any ideas? (The site I want to test is on different domain) – Zlatin Zlatev Apr 14 '14 at 16:10
  • Turned out it was because of the self-signed certificate, causing security exception in the browser. – Zlatin Zlatev Apr 14 '14 at 16:41
  • Awesome. You just saved me hours of work trying to get remote debugging working over HTTPS. – asgallant Jul 07 '14 at 21:20
  • @Dan I have been trying to implement your HTTPS solution, but I am stuck. Weinre works fine for http with bookmarklet injected. I have the correct IIS components installed, but have a couple of questions. Did you use the test machine IP address for the weinre site (E.g., 192.168.1.6)? Can you share the details of the IIS setup for step 5? What was your entry and where did you enter the server:port info. There are a number of fields to choose from. Can you provide your associated bookmarketlet code? Thanks... I can open up another stack overflow issue if you want. – Highdown Nov 20 '16 at 16:45
  • @Highdown, Just saw this; in step 5 the rewrite rule uses "http://localhost:8080/{R:1}" as the rewrite URL (with the include query string option). I haven't touched this in quite some time so my memory is hazy. – Dan Nov 29 '16 at 22:59
3

You can run weinre on a PaaS like Heroku or Bluemix, which typically provide https termination, so the apps basically get https support for free.

You can try the https version of my public access weinre server, here: https://weinre.mybluemix.net/

Patrick Mueller
  • 697
  • 1
  • 6
  • 13