#!/usr/bin/perl # Name: db_manager.cgi # Version: 6.0 # Last Modified: 04-02-98 # # Copyright Information: This application was written by Selena Sol # (selena@eff.org, http://www.extropia.com) and Gunther Birznieks # (birzniek@hlsun.redcross.org) having been inspired by # countless other Perl authors. Feel free to copy, cite, reference, # sample, borrow, resell or plagiarize the contents. However, if you # don't mind, please let me know where it goes so that I can at least # watch and take part in the development of the memes. Information wants # to be free, support public domain freware. Donations are appreciated # and will be spent on further upgrades and other public domain scripts. ####################################################################### # Flush the Perl Buffer. # ####################################################################### $| = 1; ####################################################################### # Send out the http Header # ####################################################################### print "Content-type: text/html\n\n"; ####################################################################### # Read and Parse Form Data # ####################################################################### &require_supporting_libraries (__FILE__, __LINE__, "./Library/cgi-lib.pl", "./Library/auth-lib.pl", "./Library/db-lib.pl"); &ReadParse(*form_data); ####################################################################### # Load Supporting Files # ####################################################################### # For example, you might use the following hyperlink to # direct the script to access address_book.setup: # # http://www.katsation.com/cgi-bin/db_manager.cgi?setup_file=CT_chimera.setup # # You can also send this information as a hidden field in # an HTML form using something like the following. # # # # For example, the following code would define a setup # file called address_book.setup: # # # # You might also create a select box so that the user can # choose from a number of databases dynamically: # # # # All these examples assume you placed the setup files in # the provided subdirectory called Setup_files. # # The script uses the subroutine require_supporting_libraries # documented later in this script to actually load the # setup file and all of its configuration options. $setup_file = $form_data{'setup_file'}; $setup_file =~ /([\w-.]+setup[\w-.]+)/; $untainted_setup_file = $1; &require_supporting_libraries (__FILE__, __LINE__, "./Setup_files/$untainted_setup_file"); ####################################################################### # Authenticate User # ####################################################################### # Next the script must make sure that if the admin has # instructed it to authenticate all users through the # setup file variable $should_i_authenticate, that it # provides a level of authentication. Authentication is # handled by the authentication subroutine which is # documented later in this script. if ($should_i_authenticate eq "yes") { &authentication; } ####################################################################### # Perform Management Functions # ####################################################################### # After the user has been authenticated (if necessary), it # is time for the script to perform any or all of the # management functions. # # There are 5 general functions that this script must # provide. The script must be able to 1) add a new item # to the database, 2) modify an item in the database, # 3) delete an item in the database, 4) provide the user # with a view of the database and finally 5) present # the user with a frontpage to give the user the previous # four options. # # These five general functions are broken down into # several other steps each. For example, the general step # of modifying an item in the database can be broken down # into three sub-steps. 1) The user must choose to # "Modify an Item" from a submit button on the frontpage # 2) they must be taken to a screen on which they can # enter search criteria so that the script can dynamically # generate a list of matches from which they can then # choose a specific item to modify and 3) they user must # be able to choose an item from that list, describe the # changes she wants made and then submit the changes to # the database. # # When all is said and done, there are 11 general and # sub-functions that make up the main body of logic of # this application. We will go over each as they appear # in the code below. # # The logic is broken down into a series of "if" tests. # # Specifically, the script checks the values of incoming # administrative form variables (mainly supplied from # the SUBMIT buttons on dynamically generated HTML forms) # and will perform its operations depending on whether # those administrative variables have values associated # with them or not. # # The basic format for such an "if" test follows the # syntax: # # if (the value of some submit button ne "") # { # process that type of request; # exit; # } # # For example, consider the first case in which the # customer has clicked on the "Add an Item" submit # button denoted with the NAME value of # "add_item_button". # # if ($form_data{'add_item_button'} ne "") # { # &generic_header("Add an Item to the Database Form"); # &generic_form_header; # &add_form_header; # &add_modify_data_entry_form; # &add_form_footer; # &generic_form_footer; # exit; # } # # Because the submit button will have some value # like "Add this new item", when the script reaches # this statement block, it will answer true to the test. # # Since the customer can only click on one submit button # at a time, we can be assured that only one operation # will answer true. # # The beauty of using the not equal (ne) test is that # regardless of what the submit button actually says # (it might say "Add a weiner dog to the chopping block") # the if test will still be satisfied if they have clicked # the button, since whatever the VALUE is, it will # certainly not be equal to "nothing". Of course, this # assumes that you do not rename the NAME argument of the # submit buttons. If you do so, you must harmonize the # variable you use on the input forms, with the variables # used here to test. # # Similarly, if you wish to have graphical submit buttons # instead of the ugly default buttons supplied by the # browser, you will have to modify the if tests so that # they follow the standard image map test: # # if ($form_data{'some_button.x'} ne "") # { # do something # } # # where the HTML code looks like the following: # # # # Thus, if the button actually has an X-dimension value, # it means that the button had been clicked. # # Finally, note that every if test is concluded with an # exit statement. This is because once the script is done # executing the routine specified in the submit button, it # is done with its work and should exit immediately. # # Get used to the idea that this script is "self-referencing". # The application itself contains many mini-routines # which all refer back to the routine community. Every # instance of the script need only execute maybe 1/11th of # the routines in the whole file, but in the lifetime of # the application, most, if not all, routines are # executed. # # Okay, so now let's look at each of the routines which # this applicaiton must execute. # # 1. If the user clicks the "add an item" button on the # frontpage, they must be presented with an HTML form with # input fields for each field in the database which they # have access to define. The user can then fill in the # input fields and submit the info to be added to the # database. # # The generation of this add form is handled by # several subroutines which are all defined in the setup # file. generic_header will print out the basic HTML # header with the passed parameter placed between the #