Rolling Your Own Multivalue Web Connector: Part 3
In the last couple of issues we've seen how easy it is to connect just about any MultiValue system to the web using a little bit of Basic, a little bit of PHP, and a single environment variable. Now that we have the basics out of the way, let's tie up a few loose ends as we bring this series to a close.
A couple of issues ago we saw how a minuscule Basic program can be called from the login procedure to allow other Basic routines to be run from outside of the MultiValue environment. Last issue we built upon this with a simple PHP script launched from the Apache web server that receives a request from the web and sends it to our MultiValue program, effectively connecting our MultiValue system to the web using a mere couple dozen lines of code.
So far, so good. There is, however, a dark side.
To allow Apache and MultiValue to speak freely, both need to be running on the same machine. This allows Apache to launch our MultiValue program without the complexity of authentication or networking protocols. But in that benefit, my friends, we also find our greatest risk. By intentionally circumventing security, the benefit offered by the connection is overshadowed by the unacceptable risk it presents for our MultiValue data server. So does that mean we've come this far only to fail? Absolutely not! Rather, we simply have a little more work to do.
Anyone with a shred of concern about security would never consider opening up the telnet port on our data server to the outside world. To the plethora of spammers and scammers in the wild, any open port is an invitation to wreak havoc. Yet the same could also be said of http, ssh, or any other network protocol. Though Apache does have numerous security options to secure http, the thought of any open port to the outside world should be a cause to pause and seriously consider how much risk we're willing to accept.
We can restrict Apache from accepting connections that we don't recognize, but that effectively defeats the whole point of connecting our MultiValue system to the web. We want to give people access to our information, but we don't want to give that access to the wrong people. Yet how do we know who is who? Fortunately, the problem isn't as difficult to solve as it might sound at first blush.
Because Apache is so affordably priced — that is, FREE — it costs us nothing but a little time to put up another Apache instance on a separate server. Unlike our first Apache running behind the firewall, we can freely open up this second Apache to the world. As long as we can make a reliable connection between the two, we can still offer access to our MultiValue information with much less risk to our production data servers. And with a second Apache server, we may actually improve the overall efficiency of the solution.
With PHP running on both Apache servers, connecting the two can be a snap. All we need is one of several HTTP extensions for PHP. I prefer pecl_http (php_http on Windows). Unfortunately, this extension is not installed by default. But using the PECL (PHP Extension Community Library) or a pre-built DLL for Windows, we can add it to our PHP installation in a matter of moments. Once the HTTP extension is installed, our two Apaches can speak to each other using HTTP (or HTTPS) almost effortlessly.
Once we have a public Apache open to the world and a private Apache behind the firewall (secured as described in the last installment of this series), the last thing we need is a little bit of PHP on the public Apache that will make requests of our private Apache. This could be accomplished with the WebProxy function shown in figure 1. Note the simplicity of this function: We simply build a URL to ask for a web page and it gives us back the results from the private server. Note how this simple function makes absolutely no reference to the names of our subroutines from the public Apache. Even if the public Apache gets hacked, the hacker will get limited information about your MultiValue system. In fact, the hacker likely won't even be able to tell that it is a MultiValue system!
Fig. 1
With our web proxy class in place we can now make requests from our public Apache with something as simple as the PHP script in figure 2. While this example is trivial, it does demonstrate everything we need to make a request of our private Apache and capture the information returned. In short, all we need to do is build a URL with some optional parameters and pass it into the WebProxy function and accept whatever it returns.
Fig. 2
But this brings up another question. What should our private Apache return?
A typical Apache server is responsible for all forms of web content: HTML, CSS, Javascript, images, and more. In fact, this is a perfect use of our public Apache. But for our private Apache, that's all too much. Our MultiValue data server should be responsible for serving only our MultiValue information, leaving the public Apache to pick up everything else. By moving the rendering of all of our web deliciousness to the public Apache, our private Apache, MultiValue data server, and private network will not be burdened with anything but moving information, which requires minuscule bandwidth and resources by comparison. And using a lightweight data format like JSON, you can transmit complex multidimensional structures from your MultiValue system to the web really quite easily.
While the ease of implementing this is remarkable unto itself, it is far and away not the most impressive aspect of the solution. For all of the moving pieces, this connector is remarkably fast and efficient! In fact, I have been regularly amazed at how fast my Unidata responds when it's not burdened with the screen I/O needed to maintain a working telnet-based application. Furthermore, because this solution doesn't require persistent connections "squatting" on ports, using this kind of connector can help you support more users without having to invest in more database licenses!
In closing, what we've seen in these past few installments has been just a taste of what's possible with very little code and even less financial investment. There is so much more we can do to build upon this foundation, and I encourage you to stretch your imagination dreaming of the possibilities and turning them into reality. Learn a little. Play a lot. And never stop believing in the brilliance yet to come.
