webps - v .20 Release Notes (2/2)

webps Release Notes: v.20

Maximum Sessions

A key back end improvement in this webps release is its support
for maximum session lengths, via the new max_session_length variable
of the main configuration file. When I posted the demo version of webps
I realized that the original session controlling variables of the script--namely,
session_timeout and max_sessions--would not protect
the administrator from "session hogs," those that open up a session in a browser
window and keep it open indefinitely (while they attend to other emergencies, such as
having lunch, going home, leaving on vacation, etc.). While those users are "viewing" their
webps screen, a session is taken up internally in the webps
script. If enough of these hogs take up webps sessions (i.e., if
the max_sessions parameter is exceeded), no one else will be
able to use the script until one of them shuts down.

In the original demo version, I addressed this problem by periodically dumping
all open sessions via a separate script, but later on I realized the feature
needed to be built into the main script so all administrators could manage the
length of open sessions. The new max_session_length parameter was added
in this release to solve this problem, and represents the length of time--in
seconds--that any individual may have their session open. Once the time interval
is reached, the user's sessions will automatically stop refreshing (this is enforced
on the server side, by the script itself), and the user will be forced to re-login
if they want to restart the automatic update feature. They will, however,
still be able to see the results of their last automatic update on their screen
indefinitely.

When a user hits the maximum session setting, their browser
automatically stops its automatic screen refreshes and the user
is then told that they need to relogin to restart.

Other Changes

Other less significant changes that made their way into this release of
webps include:

Added the version, admin_name and
admin_email to the login form. You may or
may not want to actually use these, especially the administrator's
E-mail address. This version allows you to
quickly see which version you're running without having to dig
into the script. If you don't want to see these in your
implementation, be sure to edit the login form template
(login_form.tmpl).

Pass refresh interval in update.xml. One of
my original design goals was to ensure that any changes made to the configuration
file would be automatically reflected in each end user's next screen
update. For example, if an administrator removes a user from the
configuration file and/or changes the fields to which they have access,
the user should no longer be able to view further updates using their
old qualifications.

I missed at least one parameter in that goal, however; when a user's
refresh interval (the length of time the user must wait before requesting
a data update) changed, the browser was unaware of it. If the refresh
interval was reduced, the user would be in danger of getting timed out
(if their old refresh interval was longer than the session timeout
setting), and if the interval was extended the browser would
send requests faster than the script could process them. By passing
the update interval back to the user as part of the delta update,
the browser can automatically adjust its own refresh interval to
match that of the server.

Other script fixes include stricter checking on user names and passwords (only
certain characters are allowed; see the README.TXT for details), and
a fix to ensure that each redraw of the main data table would be based on the user's
actual field choices (even if they're empty), to prevent the confusing scenario
where a user's choice would appear to be ignored since they made it while a previous
update was in progress (and that update, when it was completed, would then revert
the display to the prior field choices). In other words, each new display of data
is now based on the user's currently selected field choices, even if the data update
was itself based on other (previous) field choices.

Conclusion

As always, I hope this new release and documentation are helpful with your administration and/or development efforts. If you have any
suggestions for future enhancements to the script, please let me know!