[Bug] WebSocker client is not working.

[fjpanag]

Describe the bug I just upgraded to v1.3.0, and I am trying out the new WebSockets client.

Unfortuneatelly, it is not working.
I click on the "Connect" button, it gets grayed out, and nothing is happening.

I have verified that the server configuration is correct:

• I checked the open ports in docker compose, firewalls etc.
• I checked that I can connect to the WebSockets port (8084) with telnet.
• I checked in the UI that WebSockets support is enabled.
• I checked that I can properly connect to the broker using another client, with the exact same credentials and through WebSockets specifically.

It seems that only the embedded client is not working.

Your Server Environment

• Deployment: Docker
• TBMQ version: v1.3.0
• OS name and version: Rocky 9

Your Client Environment Desktop:

• OS: Fedora 39
• Browser: Firefox
• Version: 124.0.2

To Reproduce Steps to reproduce the behavior:

1. Ensure that the connection details / credentials are correct.
2. Press the "Connect" button.

Expected behavior I would expect the client to connect. Or at least throw a meaningful error in case something is wrong.

Screenshots

Notice how the "Connect" button is grayed-out, but also the client states "Disconnected".

[dmytro-landiak]

Hi @fjpanag,

Could you please share with me the docker-compose file that you are using? Additionally, I see you are trying to connect the WS Default Connection. Have you changed any of the configurations of this connection (e.g. Connection Details/Advanced Settings/Last WIll)? If yes, please send me the screenshots of the configuration.

Do you have a deployment to which I could get access (UI/ssh)? This would help a lot in the investigation.

[fjpanag]

Hello @dmytro-landiak

Could you please share with me the docker-compose file that you are using?

Here you are:

version: "3.0"
services:
  postgres:
    restart: always
    image: "postgres:15"
    ports:
      - "5432"
    environment:
      POSTGRES_DB: thingsboard_mqtt_broker
      POSTGRES_PASSWORD: postgres
    volumes:
      - tbmq-postgres-data:/var/lib/postgresql/data
  kafka:
    restart: always
    image: "bitnami/kafka:3.5.1"
    ports:
      - "9092"
    environment:
      KAFKA_CFG_NODE_ID: 0
      KAFKA_CFG_PROCESS_ROLES: controller,broker
      KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: 0@kafka:9093
      KAFKA_CFG_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://:9092
      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_CFG_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_CFG_INTER_BROKER_LISTENER_NAME: PLAINTEXT
    volumes:
      - tbmq-kafka-data:/bitnami/kafka
  tbmq:
    restart: always
    image: "thingsboard/tbmq:1.3.0"
    depends_on:
      - postgres
      - kafka
    ports:
      - "8083:8083"
      - "1883:1883"
      - "8084:8084"
      - "8883:8883"
    environment:
      TB_SERVICE_ID: tbmq
      SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/thingsboard_mqtt_broker
      SPRING_DATASOURCE_USERNAME: postgres
      SPRING_DATASOURCE_PASSWORD: postgres
      TB_KAFKA_SERVERS: kafka:9092
      SECURITY_MQTT_BASIC_ENABLED: "true"
      SECURITY_MQTT_SSL_ENABLED: "true"
      LISTENER_SSL_ENABLED: "true"
      LISTENER_SSL_CREDENTIALS_TYPE: "PEM"
      LISTENER_SSL_PEM_CERT: "/data/fullchain.pem"
      LISTENER_SSL_PEM_KEY: "/data/privkey.pem"
      JWT_TOKEN_ISSUER: "example.gr"
      SWAGGER_CONTACT_NAME: "Example"
      SWAGGER_CONTACT_URL: "https://example.gr"
      SWAGGER_CONTACT_EMAIL: "info@example.gr"
    volumes:
      - tbmq-logs:/var/log/thingsboard-mqtt-broker
      - tbmq-data:/data

volumes:
  tbmq-postgres-data:
    external: true
  tbmq-kafka-data:
    external: true
  tbmq-logs:
    external: true
  tbmq-data:
    external: true

---

Additionally, I see you are trying to connect the WS Default Connection. Have you changed any of the configurations of this connection (e.g. Connection Details/Advanced Settings/Last WIll)? If yes, please send me the screenshots of the configuration.

I have only changed the broker address from localhost to the actual broker URL.

Nevertheless, here are some screenshots of the configuration:

---

Do you have a deployment to which I could get access (UI/ssh)? This would help a lot in the investigation.

Unfortunately, this is not possible at the moment.

This is a production server, and we cannot share credentials for security reasons.

[dmytro-landiak]

Hi @fjpanag,

Thank you so much for the comprehensive details you've provided. Based on your initial description and the screenshots you shared in your follow-up message, I currently have only one hypothesis regarding why the WebSocket client may not be functioning correctly in your case.

If the user interface (UI) is being accessed over HTTPS, web browsers could require that any WebSocket connections also be secure. This means using WebSocket Secure (WSS) protocol (wss://), rather than the unsecured WebSocket (WS) protocol (ws://). In a scenario where the UI is loaded over HTTPS but the WebSocket client attempts to connect using ws://, the browser could block these connections due to security policies (specifically, the Mixed Content policy). To resolve this issue, you could ensure that the WebSocket client is configured to use wss:// when the UI is accessed via HTTPS. This would involve configuring SSL/TLS for the WebSocket server and updating the client settings to use the secure protocol.

Alternatively, could you please check whether the WebSocket client functions correctly when using HTTP for the UI? This could help determine if the issue is related to the security protocol used.

To help us understand this better, could you please provide a screenshot of your browser's console and Network tab? This could offer further insights into what might be going wrong.

Additionally, I wanted to let you know that we are planning to include more comprehensive browser console logs in future releases to aid in troubleshooting and debugging efforts.

Thank you for your assistance. Best regards!

[fjpanag]

@dmytro-landiak This seems like a valid hypothesis...

Check bellow for more details:

To resolve this issue, you could ensure that the WebSocket client is configured to use wss:// when the UI is accessed via HTTPS. This would involve configuring SSL/TLS for the WebSocket server and updating the client settings to use the secure protocol.

Will try in the next few days. It requires some effort to set up (WSS is currently disabled in this instance), but will do it and test again.

Alternatively, could you please check whether the WebSocket client functions correctly when using HTTP for the UI? This could help determine if the issue is related to the security protocol used.

Unfortunately this is not easy to test. There is a reverse proxy that does not allow insecure connections. I will check whether I can disable it temporarily or maybe I will try the above test first.

To help us understand this better, could you please provide a screenshot of your browser's console and Network tab? This could offer further insights into what might be going wrong.

Here you are!

[fjpanag]

Well, in fact I managed both tests very easily.

I can confirm that the client works when I use plain HTTP in my browser.

I can confirm that the client works when I use HTTPS and WSS.

---

You can assume this issue solved for me, but please consider adding a check or an error message for this case, so users don't troubleshoot this blindly.

[dmytro-landiak]

@fjpanag,

Thank you again for bringing this issue to our attention and for your cooperation in resolving it. We have included the proposed notification logic in our development roadmap to prevent similar cases in the future.

Closing the issue as completed.