SystemLink Forum

cancel
Showing results for 
Search instead for 
Did you mean: 

Running a separate Apache server in front of SystemLink

Not sure if anyone else is looking for something similar but it looks like I'll now be going down the route of developing a custom web application that will provide all the features to my users and direct access to SystemLink will primarily only be for test applications and myself. For my use case I've got a campus with several facilities running LabVIEW control and logging software and we'll be using SystemLink to track system calibration data, live data recording, and full rate log file storage. The front end web app will provide the UI for reporting tools used by technicians, engineers, and managers. With SystemLink not providing the ability to access the SMTP service, allowing customization some of the interfaces, not providing finer grained control for authentication, and not having any means for running scripting on the server side this approach allows me to provide a completely custom application that leaves SystemLink untouched.

 

The basic approach is to have a new Apache installation (I used xampp to get PHP, mySQL, and Apache all in one but be aware it has security vulnerabilities out of the box that are documented plenty of other places when being used for a production server) that listens on ports 80 and 443 (HTTP and HTTPS). When requests come in for a specific server name the Apache server proxies the request back to the SystemLink server to still allow direct access to SystemLink when needed. SystemLink is configured to allow only local connections (the proxy from Apache) and Apache provides the HTTPS access to the user. The separate apache server's web app will then have access to SystemLink via its HTTP APIs.

 

Here is an example of the apache configuration used to achieve this:

#ServerName - This is the main way you want users to reach the server.
#  This matches the hostname in the url location. For the Server to be reached
#  DNS must be configured to route requests for that name to this machine.

#ServerAlias - Additional URLs that the server can be accessed by.

#This configuration allows running a separate apache server instance for a custom web app but also
# proxies requests from a second location name to the SystemLink app. If the SSL cert
# includes both addresses, the same cert can be used to secure both the separate apache instance
# and the proxy back to the SystemLink server.
# Additionally, SystemLink can be configured to only allow local connections.

<VirtualHost *:80>
	#Performs redirect to secure version of app in case the user didn't start the url with https://
	ServerName app
	ServerAlias app.fqdn.com
	Redirect / https://app/
</VirtualHost>

<VirtualHost *:80>
	#Performs a redirect to the secure version of the SystemLink proxy. This allows someone to enter the machine name without having to have https:// in front.
	ServerName machinename
	ServerAlias machinename.fqdn.com
	Redirect / https://machinename/
</VirtualHost>

<VirtualHost *:443>
	#This virtualhost serves the custom web application run on the separate apache instance
	
	ServerName app
	ServerAlias app.fqdn.com
	
	#Set this to 
	DocumentRoot "D:/www/app/public"
	<Directory "D:/www/app/public">
		Options Indexes FollowSymLinks
		AllowOverride None
		Require all granted
	</Directory>
	
	SSLEngine On
	SSLCertificateFile    "conf/ssl.crt/system.cer"
	SSLCertificateKeyFile "conf/ssl.key/system.key"
</VirtualHost>

<VirtualHost *:443>
	#This virtualhost provides the SSL terminating proxy to the local SystemLink server.
	#Remote connections to this server will require a secure connection but the connection between this
	#apache instance and SystemLink in insecure. Since it's local only that shouldn't be an issue.
	
	#The CORS setting in NI Web Server should be set to allow the following machine name, IE https://machinename for resources to load properly.
	ServerName machinename
	ServerAlias machinename.fqdn.com
	
	#Make sure NI Web Server is set to a different port than 80 and that these proxy statements
	# match the port used by NI Web Server. 8080 is usually a good choice.
	ProxyPass / http://localhost:8080/
	ProxyPassReverse / http://localhost:8080/
	
	SSLEngine On
	SSLCertificateFile    "conf/ssl.crt/system.cer"
	SSLCertificateKeyFile "conf/ssl.key/system.key"
</VirtualHost>

For this example I would have a SSL cert that covers app, app.fqdn.com, machinename, and machinename.fqdn.com and I have all the standard access configuration from the httpd.conf file disabled so that every request must match one of these virtualhost configurations.

 

This setup could also be used to proxy back to NodeJS applications as well. I'll be building an application based on the Symfony PHP framework so staying in apache is perfect for me.

 

I'm curious if this is helpful to anyone; let me know if it is or if you have any questions.

0 Kudos
Message 1 of 1
(2,180 Views)