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.

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!