LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Difficulty getting NXG WebVI to communicate with LabVIEW Web Service

I am implementing some NXG Web VIs which are getting data from a LabVIEW web service which interfaces with the core system. On my development computer using plain HTTP everything is working fine. When I deploy to the production system with HTTPS enabled, things stop working. The CG LabVIEW application is built as an exe and it starts its own web service with both support for HTTP and HTTPS on ports 8002 and 8003. When I open the WebVI using HTTPS, it loads but is unable to communicate with the web service. Wireshark traces show that the WebVI connects on port 8003 and sends the initial CLIENT HELLO message to establish the secure connection. However, the web service never replies. It does acknowledge the packet containing the CLIENT HELLO message but that happens at the TCP layer. No other response from the web service occurs. The NXG Web VI timeouts, closes the connection and repeats, given that it is a dashboard and it wants reguests regular updates.

 

Anyone have an idea on what might be happening?



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 1 of 6
(2,637 Views)

As an update, it looks like the WebVI is rejecting the self-signed certificate. I modified the WebVI to not verify the server but it is still rejecting the connection.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 2 of 6
(2,587 Views)

Hi Mark,

 

Are you having issues when the WebVI is built and hosted as static files in the LabVIEW Web Service itself? I would expect a WebVI that is hosted and visited on a LabVIEW Web Service to not have issues due to self-signed certificates as that would be a same origin configuration.

 

If the WebVI is hosted from a different location, such as running in the LabVIEW NXG editor using the run command or the run in browser commands, then I would expect that the LabVIEW Web Service would need CORS enabled. Additionally, when using self-signed certificates in a CORS configuration you may need to modify the WebVI to allow for Sending a Credentialed Cross-Origin HTTP Request and modify the server allow for credentialed simple requests.

 

Also note that the Configure SSL node (including the verify server input) is not supported on the Web Server target. In desktop applications you have full control of doing the fairly dangerous task of disabling server verification but WebVIs do not have the ability to disable the browser's security features.


Milan
0 Kudos
Message 3 of 6
(2,540 Views)

I am seeing the issue both in the development environment and the deployed system. The actual web page will open on port 443 but the data channel from the NXG WebVI to the LabVIEW application web service on port 8003 gets rejected with an "unknown certificate" error. The actual web service works as I have verified it using the application Postman to send the various POST requests I use for the data transfer. I did have to disable server verification in Postman to get it to connect though. It also rejected the connection if server validation was enabled.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 4 of 6
(2,514 Views)

Hi Mark,

 

> The actual web page will open on port 443 but the data channel from the NXG WebVI to the LabVIEW application web service on port 8003

 

Does this mean you have separate servers, one for hosting the built WebVI application (on port 443) and one that is the LabVIEW Web Service (on port 8003)?

 

If they are separate servers then a WebVI served from the server on port 443 is making cross-origin requests to the LabVIEW Web Server on port 8003. If you are able to host the WebVI on the LabVIEW Web Service as static content then you can avoid cross-origin request issues.

 

However, for separate servers if you enabled client-side SSL certificates for the LabVIEW Web Service then you have to make sure the web browser you are using is configured to use those Client Side SSL certificates. For example, you should be able to visit the HTTP GET URLs for your LabVIEW Web Service directly from the browser without having to manually verify the certificate.

 

The HTTP nodes on a WebVI diagram are not able to disable server verification like you describe being done in postman. Each browser that visits the Web Service has to be correctly configured to recognize the client-side SSL certificate if client-side SSL certificates are used.


Milan
0 Kudos
Message 5 of 6
(2,499 Views)

NO, both the NI Web Server and the application web service (ports 8002 and 8003) are running on the same server. The LabVIEW based application is the interface between the WebVIs and the rest of the system. The WebVIs use HTTP to communicate with the web services to get the system data.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 6
(2,478 Views)