| home / programming / perl / webps / v.10 / 2 | [previous] |
|
These days, AJAX applications are often deployed when there's a need to
retrieve small amounts of data from the server in strictly defined formats,
especially the transfer of XML-based data. AJAX, with its key XMLHttpRequest
object, is especially well suited to this type of data exchange, since it
provides the ability to process data updates in the background of the Web
application without requiring a full page data refresh. For example, without
AJAX, webps would be forced to resend the entire ps list to the browser
each time the page needed to be updated; which might be ok if the administrator
was able to see the problem they're looking for with the first hit to the
script. But what if they wanted to see additional fields, or if the actual
problem was caused by an intermittent process--requiring that they generate
several queries to the script in succession? Without AJAX-based processing, the
entire process list would have to be sent to the user with each hit to the
script--a tremendous waste of bandwidth, since only a handful of processes would
probably see any change between requests.
While AJAX provides a tremendous advantage in its ability to send and receive only small amounts of data (which are then acted upon by client-side scripting in the user's browser), it also provides a serious drawback to the unwary: Since the data is being delivered to the client for processing, the data engine must--to at least some extent--expose its application interface to the client-side handler. And if it's visible to the client, then it's visible to the user, as well.
This means that script authors must be extra-diligent and protect the data being transmitted, as well as the authentication of the data being provided by the client--else a would-be bad guy could craft their own requests to the back-end data engine to receive data in a way that was not intended by the script's author. Of course, this diligence should be exercised with all back-end scripts; but is especially necessary with AJAX (or any other data-delivery back-end, for that matter) since the data is being served to the client in such neat, tidy packages.
Some of the precautions taken in webps include:
ps listings,
the administrator configuration file also includes settings for a
minimum refresh interval (the minimum amount of time a user must wait
before they're allowed to receive a new data update), as well as
a maximum number of total sessions that each webps script will allow
to be running concurrently.
In each of these cases, it's important to be aware that all potential
violations are checked for on the server itself, by the webps script: Nothing
is assumed to be provided correctly; even though we're providing the working
client-side interface used by the script. The reason for this is simple: A
malicious user could easily create a "fake" interface to our script,
which sends anything the bad guy wanted (such as a refresh rate of a millisecond
or less, or a request for all available fields known to
ps). And don't be fooled into thinking that
something like a referrer check on the server-side will protect you from this
type of tomfoolery (i.e., checking that the referrer for the page in question
came from the page you expected it to), since that data can easily be spoofed
by the client, as well!
While our .10 release of webps is functional, much remains that could be done with it. In no particular order, here are some things that could work their way into the script in potential future releases (provided there is enough demand for them):
If this listing of future possibilities isn't enough, send me your suggestions for other improvements you 'd like to see. In the meantime, we hope this new tool will help you with the administration of your servers!
| home / programming / perl / webps / v.10 / 2 | [previous] |
Created: July 2, 2007
Revised: July 2, 2007
URL: http://webreference.com/programming/perl/webps/v.10/2.html