[MacPerl] file uploads

[Bruce Van Allen <bva@cruzio.com>]

At 2:56 AM 12/17/00, Richard of team@team-artonomy.com wrote:

>Basically, I want to write a series of scripts that will allow us to
>administer the site using HTML Forms and CGI's (so updates can be done by
>other people without having to touch any HTML). To do this, I want to be
>able to use the <INPUT TYPE="file"> form element. Unfortunately, I have no
>idea how my CGI scripts will receive the information, or how I can process
>it. I know this is pretty obvious stuff, but any hand holding would be much
>appreciated.
>
>I want to use this form element to point to a JPEG file on the users drive,
>then upload it to a directory on a Unix server.

I have several sites and clients' sites that allow file upload via 
CGI. Among other things, these sites utilize file upload for 
pictures, text snippets to be inserted into HTML files, HTML files to 
be added to a site, data files that other CGIs use for lookups, and 
batch uploads of data. The upload capability can be public, gated, or 
entirely private.

I have migrated to using CGI.pm to handle file uploads in all cases; 
I once hacked out some code to do it, and also formerly used 
cgi-lib.pl. CGI.pm adds some overhead, but it's very capable, and I 
haven't really ever hit a performance wall with it. Plus, it comes 
with the standard Perl distribution, so it's there for you on almost 
any web server.

So, I recommend that you check out CGI.pm:

    Book: Official Guide to Programming with CGI.pm
          by Lincoln Stein, Wiley, 1998;

    Online: http://www.wiley.com/compbooks/stein/.

What you'll find for file upload is somewhat spare, but it's really 
all you need. A few notes:

1. If your server is a Mac, folks have had some difficulties with 
file uploads. Be sure to get a recent version of CGI.pm, with its 
improved file upload handling, and pay close attention to the 
existence and location of the temp file directory into which CGI.pm 
places the uploaded file until your script has processed it.

2. For processing image uploads, use read() instead of the angle 
bracket "line" input, <>.

3. Web browsers vary in whether they send along only the file name or 
the whole path, so your script will have to be capable of parsing 
paths from various OSes, unless you just ignore the file's original 
name and give it your own.

4. Don't ignore the very significant security issues involved in file 
uploads. CGI.pm, as usual, does the Right Thing: sequestering the 
uploaded file and then deleting it when the script terminates, 
leaving it to your script to read it and then write it out to the 
location where you want it to live. CGI.pm similarly contains the 
filename itself, to avoid even that opportunity for taint. To work 
with the security constraints takes a few extra lines of code, but 
it's not a biggie, so just do it.

5. On some of the sites for which I've enabled file uploading, the 
uploading is intended only for the owner, not the public. One of the 
best ways to make this secure is to have the HTML page(s) from which 
uploading is initiated located on the owner's machine or LAN, not on 
the public web server. An innocent or malicious stranger can thus 
never stumble upon the upload page, or even get a hint that there's a 
CGI there. Public or private, your upload script can require a 
password without which it will abort -- although by the time the 
script could check the password, the file will already be on your 
server. Another approach is to have the HTML for the upload page 
generated from a script, only in response to correct incantations by 
the user.

6. The length of the uploaded file will be unknown to you until your 
script reads it after it lands in your server (unless you want to do 
some JavaScript fiddling on your web page -- ugh! ;-). You might want 
your script to reject files over a certain size, or extract only a 
portion of the uploaded file to keep. CGI.pm's security measures work 
in your favor for this: if you don't affirmatively write the file to 
disk, nothing will persist past the execution of your script.

7. With images and other binaries, especially when uploaded by 
strangers, be ready for file formats that aren't Internet-suitable.

8. Also with images, you'l have to decide whether you want your 
script to modify the file. For example, if users are uploading images 
that will be dropped into HTML layouts, you might be concerned with 
the dimensions of the image, or you might want to have a fast-loading 
"thumbnail" copy. Perl image-processing modules can handle this for 
you on most platforms.

9. You may not pre-select the file to be uploaded from the user's 
machine; i.e., you can't have a default file name in the file 
selection field of the HTML upload page. So the upload process will 
have to include the user step of clicking a "Browse" button to select 
each file to be uploaded.

I don't mean to make this seem overly complicated. Using file uploads 
has made some of my clients very happy, because they can update and 
maintain their web sites without writing HTML, and without using FTP.

HTH.

1;

- Bruce

__Bruce_Van_Allen___Santa_Cruz_CA__

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org