MQTT Websockets and Browsers

[Adam Helbling]

So I've posted this up on both the paho-dev and the HiveMQ (broker I'm using) support lists/pages.

I can't seem to find any consensus on what the problem might be so please excuse me for posting here, but thought there may be some other people who have insight into this.

My problem in summary is "I cannot connect to my broker from a web browser using the paho js software without first point the browser to the port of my running broker". This does not seem normal.

Since I am unsure as to whether this is a server, client, configuration, or browser issue I figured readers of this list would have a good understanding of how MQTT should work. I have begun to comb through the RFC 6455 more to get a better understanding of how the websockets should play with MQTT.

So my problem is such (more or less quoted from paho-dev archive):

I have started a discussion about my issue over at the HiveMQ Google Group which goes over my issue. To be clear, I am having a hard time pinpointing what may be the component causing my setup problems (broker, client browser, or paho javascript). Specifically, the problem is that I need to first visit my broker at the specific port it is running on prior to trying to open a WebSocket via the Paho Javascript. Once I've visit https://myserver.com:8444 I am then able to establish a secure WebSocket with the Mqtt broker using the paho javascript API.

System components:

* HiveMQ 1.4.4 - Configured to use Websockets over SSL

* Paho javascript code

* DigiCert Signed SSL key/certificate

My problem is easily replicated in Chrome (Version 33). I have written javascript which leverages the Paho javascript that is running on a private server, but for testing purposes the publicly available HiveMQ Websocket client works just fine. I have added the screenshots of the steps I take.

If I start a fresh browser and point the host field to my HiveMQ broker and try to access I get the following pop-up.

Screenshot1.png Attached

To resolve I go to https://myserver.com:8444 and see the following message "not a WebSocket handshake request: missing upgrade".

Screenshot2.png Attached

Then I go back to the client and connect and have no issue.

Screenshot3.png Attached

Thank you for any help resolving this.

[Tobias Oberstein]

> My problem in summary is "*I cannot connect to my broker from a web

> browser using the paho js software without first point the browser to

> the port of my running broker*". This does not seem normal.

When you do visit the WS endpoint first in your browser (using https),
are you getting _any_ certificate warnings (that you then ack)?

If so, that's a problem. Since: WebSocket is a so-called "subresource"
from a browser point of view. That means: the browser will never render
any user dialogs - including "accept invalid cert anyway".

Also: Firefox will allow you do accept "once and for all" an invalid
cert. Chrome not.

/Tobias

[Roger Light]

Hi Adam,

I presume you've verified that this setup works when not using TLS?

Cheers,

Roger

> --
> To learn more about MQTT please visit http://mqtt.org
> --- You received this message because you are subscribed to the Google
> Groups "MQ Telemetry Transport" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.

[Adam Helbling]

@Tobias - I do not get any certificate warnings. As the cert is a valid cert. Now with that said, on our main domain address we use proxy redirects, but NOT when specifying ports. So when pointing the browser to :8444 (port in my case) we are using purely our HiveMQ's code to handle the request. However, when going to https://<myserver.com> which runs the javascript to then do the connect it does use an Apache proxy. 

@Roger - Yes, it works without TLS. Which is why I did feel it was something to do with that. However, regardless of the address I go to the cert is never asked by the browser to be verified. Also, after going to :8444, as mentioned, we have no issue with the cert/keys since the client and server work perfectly fine. Which tells me that the keys are fine in HiveMQ since it is able to decrypt/encrypt the communication with the client.

I really appreciate both (and any) of your help. This one really has stumped me.

--
Adam H.
(m) 860.227.8662 (Verizon)
(m) 603.685.4161 (GoogleVoice)

[Adam Helbling]

Ok, with the help of the fine people over at HiveMQ, I narrowed this problem down and have come up with a solution that seems healthy.

I put the following into my javascript, just before calling 'connect' on my Paho Websocket Client. Basically, its just an ajax workaround, to have the browser make a call to the address that I've been having to open in a separate tag. I should also note, that this issue is mostly evident in Chrome (which is where the fix has been confirmed). The other browsers work with this code (or without it). So for anyone with a similar issue go ahead and just make an ajax call to the address:port of your mqtt broker and you should be good to go.

$.ajax({url: 'https://' + host + ':8444/mqtt',

          success: function(result) {

                console.log(result);

          },

          error: function(jqXHR, textStatus, errorThrown, result) {

                console.log('Error: ' + textStatus + ' ' + errorThrown, jqXHR);

          }

    });

Cheers,

Adam H.