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

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!