webps - v .10 Release Notes | 2 | WebReference

webps - v .10 Release Notes | 2

To page 1current page
[previous]

webps Release Notes: v.10

Server-side Error Checking

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:

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!

Future Considerations

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):

Conclusion

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!

Digg This Add to del.icio.us


To page 1current page
[previous]

Created: July 2, 2007
Revised: July 2, 2007

URL: http://webreference.com/programming/perl/webps/v.10/2.html