Rolling Your Own MultiValue Web Connector - Part 2
In "Rolling Your Own MultiValue Web Connector — Part 1," we created a simple bit of code to allow a Basic subroutine to be invoked from outside of your MultiValue environment. With a subroutine like this and one environment variable we can take the first step to untethering our MultiValue applications from Telnet.
Believe it or not, going from here to the web is a very short step. All we need is a web server, PHP, and one dinky little script. (This procedure could be accomplished with just about any scripting language but we'll stick with PHP because of the awesome session management features discussed previously.)
Starting with the web server, we have a couple of options. If you fancy Microsoft "technologies" feel free to use IIS. On the other hand if you are more interested in things just working with fewer headaches, the Apache web server is a beautiful thing. Apache runs on Windows too!
In November 2011, Netcraft published a survey stating that Apache runs two times more websites than every other web server combined (intl-spectrum.com/s1047). Whether you're running your MultiValue database on Windows, *nix, or something else, there's likely an Apache version for the platform. Visit http://httpd.apache.org for downloads, details, and documentation, or visit the website for your specific OS vendor to find a platform specific build. However, don't go downloading just yet as we have some important details yet to discuss.
"WAIT A MINUTE," I can hear you say. "Are you suggesting that we put a web server alongside our MultiValue database and all of our confidential and priceless information?" As a matter of fact, I am suggesting exactly that. With that in mind, please restrain your security ninja for the time being as there is much more to this puzzle than just dropping Apache on the same server as your MultiValue database.
While Apache is known as a web server , that doesn't mean it has to serve web pages . Rather, Apache is a brilliant example of an efficient, highly scalable, and highly securable threaded server that can be used to serve up just about anything using the simple http and secure https protocols. In this example, we'll be serving up MultiValue data with the Basic subroutines created last time and a little bit of PHP. Next time we'll finish up this series with another Apache instance and a little more PHP to tie things together nice and securely.
For all intents and purposes, the Apache server sitting next to our MultiValue database (let's call it the "private Apache") will be used only to read from and write to our database. It will fulfill requests for information only from the other (let's call it the "public Apache") server. The public Apache server will then be responsible for serving all of the web content including HTML, Javascript, CSS, and images to support the user interface for our web applications. This division of labor will allow our MultiValue system to serve up data assets with no impact or concern for all of the web deliciousness you might choose to use on your public facing server.
Note the word "only" in the previous paragraph. It's critically important to security that the private Apache be restricted to accept connections only from the public Apache server. Fortunately, this is easily configured. It is also important to the overall efficiency of the solution that the private Apache not be burdened with serving HTML, CSS, Javascript, and images.
Installing Apache and PHP on Windows systems is an absolute breeze, as the installers do all the heavy lifting to integrate PHP into Apache. Installing on Linux is usually even easier because most distributions either have it installed by default or have everything you need in one or more convenient installation packages. To save some space I won't get into the details of all that here, but if you're interested in learning more I'll be demonstrating the installation procedure in detail at the 2012 Spectrum conference.
Once Apache and PHP are installed, the next step is to create that little bit of script that allows Apache to set the appropriate environment variables and launch our MultiValue environment. (See "Rolling Your Own MultiValue Web Connector — Part 1" in the Jan/Feb 2012 Spectrum magazine for more details about this part.)
Figure 1 shows how this could be accomplished. We start by retrieving a request variable ("subrName") to tell us the name of the MultiValue Basic subroutine to be called. If this variable is set, we calculate a somewhat unique name for our output file, extract the data from another request variable ("data"), and build our environment variable to send into our shell — Unidata, in my case.
Fig. 1
Next, we set the environment variable as expected by our Basic connector, change to the appropriate directory, and start up the Unidata shell. When this is done we simply read the output that was written by the Basic subroutine, display it, do a bit of cleanup, and the process is complete.
The astute among us will immediately notice that this example does no error checking. This is intentional to promote simplicity of the example. With this much working, one could easily add error checking and other features expected of a more customer-ready solution.
With all of these pieces in place, we can now call our TEST.SUB subroutine (from last issue) from a browser. By entering a URL like the one shown in figure 2, we can call our Basic subroutine to convert the input to lower case, as shown in the browser window. Admittedly this example has a slightly anticlimactic end result, but with more powerful subroutines perhaps you can see how we could do just about anything in our MultiValue system, all from the context of a web browser.
Fig. 2
With all that working, we once again return to the issue of security. Obviously, we don't want to be allowing just anyone access to this private Apache server because right now it provides unrestricted access to your MultiValue information. (While the solution is restricted by the subroutines written for it, that's just not restricted enough.)
The default configuration for Apache on Windows is usually wide open, allowing connections from anyone anywhere, and is therefore far too open for our tastes. However, using the simple Order, Allow, and Deny directives in our configuration, we can lock it all down pretty tight. These directives can be used in a variety of places in your Apache configuration, but as a simple introduction we could open our httpd.conf file (the Apache configuration file) and look for something like figure 3.
<Directory "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs">
This is the configuration block for the default "localhost" in a standard Windows install. Near the bottom of this block you'll see something that looks like this:
# # Controls who can get stuff # from this server. # Order allow,deny Allow from all
Let's say we only want to be able to restrict this server so that it can only be accessed locally - not from anything else on the network. This simple change will accomplish that objective:
Order deny,allow Deny from all Allow from 127.0.0.1
The Order statement says to check the Deny statements first, then apply any Allow statements afterward. "Deny from all" denies … well, everyone! Finally, by allowing access from 127.0.0.1, Apache will only accept requests from its own server.
With this change in place, we're a simple Apache restart away from a much more secure solution.
