Now that the essential structure of this data entry scheme is in place, I'm ready to start actually pulling the records into the database. Or am I? Let's think about this for a minute. The script as it exists now geta a number of records from the user, writes them to a file, and then loops back t do the same thing all over again. Obviously, with this structure we're not going to have more than one user entering at the same time ... I'd have to make the script pause or they'd be stomping all over that output file before the records were actually in the database. Even if I were to do something really clunky and have users run slightly different versions of the script that specify different destination files, there is no guarantee that the records would be saved before another iteration of the script being run by any given user came back to the point of writing the file. I could have the script actually insert the records, but as I've discussed before and will again shortly I've decided that I don't want to place the overhead of waiting for that to happen on the executioin of the script. (Put another way, I don't want the user to have to wait for the addition to the database to finish.) What I should do is figure out some coherent scheme for writing a unique file each time around.

To do that, it is clear that the script is going to have to dynamically generate the filename under which the records will be saved each time around. The wrinkle that this adds to the script lies in the operation of taint checking. If you recall, taint checking attempts, as much as possible, to make sure that values not generated by the script cannot be used by a malicious user. The process of taint checking essentially involves putting a level of perl insulation on top of the submitted value so it can't be used to execute a command on the server. I may get further into the actual process of taint checking at some point, but for now what we want is a perl mechanism to specify how things should be written in a fashion that co-exists with taint checking.

The scheme ultimately used to assign the filename is the third I've tried; I'll go through the first two just as an illustration of the path development can take. My first shot involved reading the IP address in the REMOTE_HOST environment variable and using that as the basis for the filename. Since this comes from the environment, and is external to the script, I ran into difficulty with taint checks when I attempted to create the filehandle (the hook to the specified external file that perl uses). This difficulty was ultimately resolved through the use of the FileHandle::Deluxe module, but as I worked through the problem it occurred to me that as it is possible to spoof an IP address in an http request it would be possible to store a command in that variable. While that possiblility might be relatively remote, most security vulnerabilities are based on problems far more obscure. Given that, I determined to adopt another approach.

My second approach involved simply using a counter scalar that would have been progressively incremented as new users accessed the script. This was and is a workable solution that I had trouble implementing for reasons I ultimately found to be attributable to problems with the Ralphzilla system. In the process of trying to resolve that problem I derived a third approach that I felt was likely to operate mote quickly than the counter approach, and the following discussion revolves around that one. I would suggest that sometimes things work that way. As you grapple with difficulties in implementing some type of structure you find yourself approaching it from different angles, and it is in such contexts that you derive more sophisticated and elegant approaches that you feed back into your overall way of doing things. I know this sounds silver-lining optimistic, but the times when the straight-forward solution you had envisioned does not work as expected are also the times when you are forced into looking at things from different angles. If you can refrain from letting anxiety dictate your approach in such circumstances, you'll find that these are the times when your overall productivity makes the most dramtic improvements. It just doesn't feel like it at the time <grin>.

I have related that story primarily to suggest that such steps are perfectly appropriate to take when trying to diagnose a problem. One of the first things I look for when I'm trying to resolve a difficulty are elements of the construct that differ from the norm in some regard. It is not at all unusual to discover that an element of the software environment upon which an application rests has difficulty with a specific technique employed in the application. Furthermore, while that difficulty may be resolved by a later version of whatever package had that problem, that later version may be dependent on a software library that creates conflicts with some other component of your system. To generate an example pertinent to Ralphzilla, it's as if an upgrade to fix a problem required a library that did not respond appropriately to requests sent to it by a component of the mosix suite. In the Windows world, applications running on versions prior to Windows 2000 frequently create problems for each other by installing custom versions of common system libraries that don't implement a given function in the manner other applications expect it to be implemented. (Windows XP and, to a lesser extent, Windows 2000, resolve that issue by implementing mechanisms in which multiple copies of those files can co-exist, but that's another discussion.) This sort of thing is absolutely possible in the software world, and perhaps even more so in the open-source part of that world, which relies on cooperation between entities that are "loosely-coupled". While open-source advocates have an extensive set or arguments suggesting that their model of development will tend to evolve more dynamically, it is nonetheless true that for any given permutation of components there is a potential that a specific version of a component will have some level of trouble with something you are trying to implement. Just keep that in mind. It is quite possible that when you run into a problem, it is not due to a flaw in your work. Break the construct you've created into smaller components, and make sure that those elements are functioning appropriately, that what is returned from a given function call is what you expect to have returned. You may have to develop an alternate expression for what you are trying to do.

After generating the $session_id scalar, a pattern match is executed within an if statement, determining whether that specific $session_id has previously been used and stored in the file referenced by the $session filehandle object. The specific statement used says, in effect, to look through that entire file for an occurence of the string held in $session_id, and to look for that string on a single line. If the pattern is not there, store "1" to the $session_test scalar, which means that it is okay to continue. Perl's pattern matching and regular expression capabilites are a powerful feature of the language, and more than a few books have been written specifically on that, so I won't attempt an extensive treatment of the subject here. Take a look at the links page, I'll find some good references and post them there. Very briefly, the pattern match operator in perl is "=~", which effectively translates into "contains the pattern following". The negation of that, "does not contain the following pattern", is expressed as "^~", and is what I use here. You may note that I originally set the scalar $session_test to represent a condition that would not let the execution of the script out of the loop, and require that the pattern match not find a $session_id before it can continue. I could have set that value to "1", and have a positive result to the pattern match set the $session_id to "0", the logic of either statement is equivalent to the other in a mirror image fashion. I generally prefer to construct key conditional tests in this manner, because in more complex pattern matches there may be ways in which an expression framed in a way that is just slightly wrong could return a false positive result. It is also easier to debug a context in which the script in which execution is never let out of a loop than it is one in which it is always let out of that loop. You may never recognize the latter ... I guarantee you will always recognize the first.<grin>

Obviously, this pattern match and the file holding used session ids is only relevant as long as at least one other user is accessing the system, but there is no ready way to determine when a given session id is not longer active, beyond constructing some sort of system for recording the time of the last exchange associated with that session id and making some assumptions about the appropriate time-out value for a given session. Given the large number of potential session ids, it would be far less clunky simply to schedule a cron job (an automatic job run by the linux system) to delete this file at a time when no one would be using the system, perhaps at 4am each morning. A cron job like this could ultimately have a wide range of system clean-up functions to perform, I wouldn't be surprised if I revisit the concept sometime down the road. In the absence of that, you could simply manually delete the file before the system came in use for a given game.

Back in the main body of the script, we now have scalars holding a unique session id, an indication that this is the first pass through the script, and the value "start" in the scalar $action. Just as in the previous incarnation of the script, that value in $action will send the script into the sel_form subroutine. While in this circumstance I could as well have used the value of $pass to do that, I want to retain as much of the structure from the previous incarnation as possible, and using $action represents a cleaner implementation of the main body event handler.

In this incarnation, the sel_form and the get_form subroutines are very much the same as they were in the previous version, the only real difference being that each ahs lines printing hidden fields holding the values to $session_id and $pass back to the client. The store subroutine, however, has been substantially modified.

sub store 		{
		$forms->delete('action');
		$forms->delete('pass');
		my $file='/home/www/save/recs'.$session_id.$pass.'.txt';
		my $recs=new FileHandle::Deluxe($file,append=>1,safe_dirs=>['/home/www/save'],
									lock=>LOCK_EX) or die "can't open file";

At this point I construct a scalar to hold the name of the output file, and use that scalar to create a filehandle object on a file of the specified name. Recall that there were two primary considerations that drove this iteration of the script:

1: Since it is possible that the application will be used in a multiple-user context, the file save by each user should have a unique name. It was this consideration that led to the incorporation of the session id to uniquely identify any given entry session.

2: Given that I decided to maintain a single id for any given session, but didn't want to assume that the file would be gone by the time a new file was ready to be written, I needed a way to give the file a slightly different name each time around while maintaining the ability to group the files from any individual session. (That grouping has no bearing on this iteration, but I wouldn't be surprised to see it surface as a feature somewhere down the road. This led to the development of the $pass counter.

In the next line the $recs filehandle is created as a FileHandle::Deluxe object. This is precisely the kind of context for which taint-checking was devised, because the screen is accepting input from the user. The FileHandle::Deluxe object creation is specifying, in essence, how the stream of data written to that object should be handled. In this case, I am saying that the object should be associated with the file specified in the $file scalar, that it should be opened in append mode (i.e., with read, write, and create permissions), that the directory "/home/www/save" should be considered safe, and that the file should be opened with an exclusive file lock. In general, what is being said here (among other things) is that the specified file, being written to a directory considered as safe, should be considered as safe from the standpoint of taint-checks. The exclusive lock that I place on the file has a different purpose, that I'll get to as I discuss the script that actually stores the records.

Following filehandle object creation, the subroutine proceeds much as it did before. You may notice that I've changed the format of the output record from the comma-delimited form used previously to one in which the data elements are delimited by the string "ZzZ".

my $line=$ecj."ZzZ".$rcj."ZzZ".$pcj."ZzZ".$ercj."ZzZ".$etj."ZzZ\n";