WEB BASED VIPW


The main means for a sysadmin to edit information in the database on the fly will be a web based application that will allow the sysadmin to search the database for information and edit it. The general outline of the application's behavior starts with the administrator entering a URL into a web browser. They will then be prompted to enter their username and password into a radius login window. They will be presented with a greeting screen and a command menu. From this menu they will be presented with several search choices that essentially maintain the divisions one is used to with the standard UNIX flat file system. These searches will then present a paged list (X entries with a prev/next choice) of hyper links for the user to look at. If the user is in the ACL with edit permissions, they will see edit buttons next to the entries. If the user clicks on the link, they will see a notecard format screen of all the user's vital information (or group's).  If they hit the edit button, they will be prompted with a second radius login. This is to prevent users with permission from leaving their web browser on the search page and allowing passersby to muck with the password/shadow/group files. They will get an editable notecard view of the vital info. This section will time out after a little while for security purposes. They will most likely be presented with the existing data with a matching text/form box near it for them to enter the new data. When they submit, the change, the system will check that the data has not changed since the last read. If it hasn't the write is completed, and a message stating such is displayed. If it has changed, the new notecard is redisplayed with the edited (form) fields intact, and the changed reference date in place and probably in a noticeable color. After the edit is complete, the user will be forced to logging again to do a new edit (edit login, not the whole application login). The application will connect to the DB through the RATS client side daemon rather than directly. This means it will be allocated a number of API calls. We have not yet decided if it will be better to restrict the api calls to the host with the DB on it and require the web server for this app to reside on the DB server, or to permit remote access to the API calls. We do however recommend that this application be run on a secure web server. In addition, to the security already described, the sysadmin may also make the cgi executable or not as needed so the application is not available 24-7 for people to attack. Keep in mind that this application is for small on the fly changes, and is not meant for altering large portions of data at one sitting. The double login is ugly, but it is essential to keep people from walking away from the application and leaving a point and click hole in their security. On the other hand, people leave their desks with their doors open and their workstations unlocked with root logins.