<p>Your message could not be encrypted, so has not been sent. <p>Sorry.”; } ?> In order to make this code work for you, you will need to change a few things. Email will be sent to the address in $to_email. The line putenv(“GNUPGHOME=/tmp/.gnupg”); will need to be changed to reflect the location of your GPG keyring. On our system, the Web server runs as the user nobody, and has the home directory /tmp/. We are using the function tempnam() to create a unique temporary filename. You can specify both the directory and a filename prefix. We are going to create and delete these files in around one second, so it is not very important what we call them. We are specifying a prefix of ‘pgp’, but letting PHP use the system temporary directory. The statement $command = “/usr/local/bin/gpg -a “. “ recipient ‘Luke Welling <luke@tangledweb.com.au>’ “. “ encrypt -o $outfile $infile”; sets up the command and parameters that will be used to call gpg. It will need to be modified to suit you. As with when we used it on the command line, you need to tell GPG which key to use to encrypt the message. The statement system($command, $result); executes the instructions stored in $command and stores the return value in $result. We could ignore the return value, but it lets us have an if statement and tell the user that some- thing went wrong. When we have finished with the temporary files that we use, we delete them using the unlink() function. This means that our user’s unencrypted email is being stored on the server for a short time. It is even possible that if the server failed during execution, the file could be left on the server. Implementing Secure Transactions with PHP and MySQL C HAPTER 15 15 I MPLEMENTING S ECURE TRANSACTIONS 345 LISTING 15.2 Continued 19 7842 CH15 3/6/01 3:40 PM Page 345 While we are thinking about the security of our script, it is important to consider all flows of information within our system. GPG will encrypt our email and allow our recipient to decrypt it, but how does the information originally come from the sender? If we are providing a Web interface to send GPG encrypted mail, the flow of information will look something like Figure 15.5. E-commerce and Security P ART III 346 3 Recipient’s Mail Server 2 Sender’s Browser Recipient’s Mail Client Web Server 1 FIGURE 15.5 In our encrypted email application, the message is sent via the Internet three times. In this figure, each arrow represents our message being sent from one machine to another. Each time the message is sent, it travels through the Internet and might pass through a number of intermediary networks and machines. The script we are looking at here exists on the machine labeled Web Server in the diagram. At the Web server, the message will be encrypted using the recipient’s public key. It will then be sent via SMTP to the recipient’s mail server. The recipient will connect to his mail server, probably using POP or IMAP, and download the message using a mail reader. Here he will decrypt the message using his private key. The data transfers in Figure 15.5 are labeled 1, 2, and 3. For stages 2 and 3, the information being transmitted is a GPG encrypted message and is of little value to anybody who does not have the private key. For transfer 1, the message being transmitted is the text that the sender entered in the form. If our information is important enough that we need to encrypt it for the second and third leg of its journey, it is a bit silly to send it unencrypted for the first leg. Therefore, this script belongs on a server that uses SSL. If we connect to our script using a port other than 443, it will provide a warning. This is the default port for SSL. If your server uses a non-default port for SSL, you might need to modify this code. Rather than providing an error message, we could deal with this situation in other ways. We could redirect the user to the same URL via an SSL connection. We could also choose to ignore it because it is not usually important if the form was delivered using a secure connec- tion. What is usually important is the details that the user has typed into the form are sent to us securely. We could simply have given a complete URL as the action of our form. 19 7842 CH15 3/6/01 3:40 PM Page 346 Currently, our open form tag looks like this: <form method = post action = send_private_mail.php> We could alter it to send data via SSL even if the user connected without SSL like this: <form method = post action = “https://webserver/send_private_mail.php”> If we hard code the complete URL like this, we can be assured that visitors’ data will be sent using SSL, but we will need to modify the code every time we use it on another server or even in another directory. Although in this case, and many others, it is not important that the empty form is sent to the user via SSL, it is usually a good idea to do so. Seeing the little padlock symbol in the status bar of their browsers reassures people that their information is going to be sent securely. They should not need to look at your HTML source and see what the action attribute of the form is. Further Reading The specification for SSL version 3.0 is available from Netscape: http://home.netscape.com/eng/ssl3/ If you would like to know more about how networks and networking protocols work, a classic introductory text is Andrew S. Tanenbaum’s Computer Networks. Next That wraps up our discussion of e-commerce and security issues. In the next section, we’ll look at some more advanced PHP techniques including interacting with other machines on the Internet, generating images on-the-fly, and using session control. Implementing Secure Transactions with PHP and MySQL C HAPTER 15 15 I MPLEMENTING S ECURE TRANSACTIONS 347 19 7842 CH15 3/6/01 3:40 PM Page 347 19 7842 CH15 3/6/01 3:40 PM Page 348 IN THIS PART 16 Interacting with the File System and the Server 351 17 Using Network and Protocol Functions 369 18 Managing the Date and Time 391 19 Generating Images 401 20 Using Session Control in PHP 429 21 Other Useful Features 447 Advanced PHP Techniques PART IV 20 7842 part 4 3/6/01 3:35 PM Page 349 20 7842 part 4 3/6/01 3:35 PM Page 350 CHAPTER 16 Interacting with the File System and the Server 21 7842 CH16 3/6/01 3:40 PM Page 351 Advanced PHP Techniques P ART IV 352 In Chapter 2, “Storing and Retrieving Data,” we saw how to read data from and write data to files on the Web server. In this chapter, we will cover other PHP functions that enable us to interact with the file system on the Web server. We will discuss • Uploading files with PHP • Using directory functions • Interacting with files on the server • Executing programs on the server • Using server environment variables In order to discuss the uses of these functions, we will look at an example. Consider a situation in which you would like your client to be able to update some of a Web site’s content—for instance, the current news about their company. (Or maybe you want a friendlier interface than FTP for yourself.) One approach to this is to let the client upload the content files as plain text. These files will then be available on the site, through a template you have designed with PHP, as we did in Chapter 6, “Object Oriented PHP.” Before we dive into the file system functions, let’s briefly look at how file upload works. Introduction to File Upload One very useful piece of PHP functionality is support for HTTP upload. Instead of files com- ing from the server to the browser using HTTP, they go in the opposite direction, that is, from the browser to the server. Usually you implement this with an HTML form interface. The one we’ll use in our example is shown in Figure 16.1. FIGURE 16.1 The HTML form we use for file upload has different fields and field types from those of a normal HTML form. 21 7842 CH16 3/6/01 3:40 PM Page 352 As you can see, the form has a box where the user can enter a filename, or click the Browse button to browse files available to him locally. You might not have seen a file upload form before. We’ll look at how to implement this in a moment. After a filename has been entered, the user can click Send File, and the file will be uploaded to the server, where a PHP script is waiting for it. HTML for File Upload In order to implement file upload, we need to use some HTML syntax that exists specially for this purpose. The HTML for this form is shown in Listing 16.1. LISTING 16.1 upload.html—HTML Form for File Upload <html> <head> <title>Administration - upload new files</title> </head> <body> <h1>Upload new news files</h1> <form enctype=”multipart/form-data” action=”upload.php” method=post> <input type=”hidden” name=”MAX_FILE_SIZE” value=”1000”> Upload this file: <input name=”userfile” type=”file”> <input type=”submit” value=”Send File”> </form> </body> </html> Note that this form uses POST. File uploads will also work with the PUT method supported by Netscape Composer and Amaya. They will not work with GET. The extra features in this form are • In the <form> tag, you must set the attribute enctype=”multipart/form-data” to let the server know that a file is coming along with the regular form information. • You must have a form field that sets the maximum size file that can be uploaded. This is a hidden field, and is shown here as <input type=”hidden” name=”MAX_FILE_SIZE” value=”1000”> The name of this form field must be MAX_FILE_SIZE. The value is the maximum size (in bytes) of files you will allow people to upload. • You need an input of type file, shown here as <input name=”userfile” type=”file”> Interacting with the File System and the Server C HAPTER 16 16 INTERACTING WITH THE F ILE SYSTEM AND THE SERVER 353 21 7842 CH16 3/6/01 3:40 PM Page 353 You can choose whatever name you like for the file, but keep it in mind as you will use this name to access your file from the receiving PHP script. Writing the PHP to Deal with the File Writing the PHP to catch the file is pretty straightforward. When the file is uploaded, it will go into a temporary location on the Web server. This is the Web server’s default temporary directory. If you do not move or rename the file before your script finishes execution, it will be deleted. Given that your HTML form has a field in it called userfile, you will end up with four vari- ables being passed to PHP: • The value stored in $userfile is where the file has been temporarily stored on the Web server. • The value stored in $userfile_name is the file’s name on the user’s system. • The value stored in $userfile_size is the size of the file in bytes. • The value stored in $userfile_type is the MIME type of the file, for example, text/plain or image/gif. You can also access these variables via the $HTTP_POST_FILES array, as follows: • $HTTP_POST_FILES[‘userfile’][‘tmp_name’] • $HTTP_POST_FILES[‘userfile’][‘name’] • $HTTP_POST_FILES[‘userfile’][‘size’] • $HTTP_POST_FILES[‘userfile’][‘type’] Given that you know where the file is and what it’s called, you can now copy it to somewhere useful. At the end of your script’s execution, the temporary file will be deleted. Hence, you must move or rename the file if you want to keep it. In our example, we’re going to use the uploaded files as recent news articles, so we’ll strip out any tags that might be in them, and move them to a more useful directory. A script that does this is shown in Listing 16.2. LISTING 16.2 upload.php—PHP to Catch the Files from the HTML Form <head> <title>Uploading </title> </head> <body> <h1>Uploading file </h1> Advanced PHP Techniques P ART IV 354 21 7842 CH16 3/6/01 3:40 PM Page 354 . Using Session Control in PHP 429 21 Other Useful Features 447 Advanced PHP Techniques PART IV 20 7842 part 4 3/6/01 3:35 PM Page 349 20 7842 part 4 3/6/01 3:35 PM Page 350 CHAPTER 16 Interacting with. enctype=”multipart/form-data” action=”upload .php method=post> <input type=”hidden” name=”MAX_FILE_SIZE” value=”1000”> Upload this file: <input name=”userfile” type=”file”> <input. file upload works. Introduction to File Upload One very useful piece of PHP functionality is support for HTTP upload. Instead of files com- ing from the server to the browser using HTTP, they