webps - v .10 Release Notes | 2

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:

Taint-mode is enabled.
The user is authenticated on every access to the script. Initially, the user is authenticated via a provided username and password in the traditional way; but following this initial authentication, a unique session ID is generated that is passed with all requests from that point forward (until the user closes their session; i.e., navigates to another page and/or logs into the script with their username and password again). Using a session ID prevents us from having to pass the user's password to the server application multiple times (even in an encoded form).
The user's selected display fields are validated against a list of fields that are allowed to be displayed for this user (or a list of fields that are allowed to be displayed for all users, if this user has no specific field restrictions).
To avoid the possibility of a user "hammering" the script to force it to generate too-frequent 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!

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

Filtering: The processes actually included within the list sent to the user could be filtered; such as filtering by user, command name, percentage of memory consumed, and so forth. Such filtering should probably be processed on the server side of webps; which would be under administrator control (certain users may need to have filters forced upon them, for example) and the user would also benefit from less data having to be sent to the browser on each refresh.
Searching: Similar to filtering, a search function would enable users to find a particular field with a particular value quickly. This feature would most likely be applied on the client-side only.
Drag-n-Drop: The user-interface itself could use some convenience updates; such as drag-and-drop field selection (perhaps a bit more intuitive to the user) or field sorting (determing how the fields are ordered left-to-right on the page).
Field Ordering: Speaking of which, a nicer way of ordering the fields in the main display table is needed (i.e., the left-to-right ordering of the displayed fields). Currently, you can order the fields any way you want; but to do so you must first delete all the fields that are already listed (except PID which is required) and then reselect your desired fields in the order you want them displayed. Far from user-friendly!

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