#!/usr/bin/perl
#
# filechucker.cgi - trial version
#
# NOTE: THIS TEXT FILE IS THE TRIAL VERSION OF FILECHUCKER.
# SAVE IT TO YOUR COMPUTER THEN UPLOAD IT TO YOUR SERVER AND
# NAME IT "filechucker.cgi". SEE FULL INSTRUCTIONS HERE:
#
# http://encodable.com/filechucker/#instructions
#
# This program is the copyrighted work of Encodable Industries.
# Redistribution is prohibited, and copies are permitted only for
# backup purposes. You are free to modify the program for your
# own use, but you may not distribute any modified copies of it.
#
# Use of this program requires a one-time license fee. You can
# obtain a license here:
#
# http://encodable.com/filechucker/#download
#
# This software comes with no warranty. The author and many other
# people have found it to be useful, and it is our hope that you
# find it useful as well, but it comes with no guarantees. Under
# no circumstances shall Encodable Industries be held liable in
# any situation arising from your use of this program. We are
# generally happy to provide support to all our users, but we can
# make no guarantee of support.
#
# For more information about this program, as well as for help
# and support, please visit the following pages:
#
# Homepage: http://encodable.com/filechucker/
# Contact: http://encodable.com/contact/
my $version = "3.78t-e05";
$ENV{PATH} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
($ENV{DOCUMENT_ROOT}) = ($ENV{DOCUMENT_ROOT} =~ /(.*)/); # untaint.
#use Time::HiRes 'gettimeofday';
#my $hires_start = gettimeofday();
my (%PREF,%TEXT) = ();
############################################################################
###
### User preferences ("PREFs") section: adjust these variables
### to suit your own server/setup/tastes. If you'd rather store
### and edit these in a separate file (to make upgrades easier,
### etc.) then create a file called filechucker_prefs.txt in the
### same directory as the filechucker.cgi script. The format for
### the lines is the same as here in the script itself; you could
### just copy or move this entire section into your separate PREFs
### file if you'd like. Comments (that is, lines starting with a
### pound-sign) and blank lines are allowed in the separate PREFs
### file, too.
###
############################################################################
#
#
# PREFs Table of Contents:
#
#
# PREFs Section 01: Debugging.
# PREFs Section 02: Paths and Directories.
#
# *Note: stop here and get the script running before customizing anything else.
#
# PREFs Section 03: Security.
# PREFs Section 04: User-directories.
# PREFs Section 05: Subdirectories.
#
# *Note: User-directories and subdirectories are two separate things.
#
# PREFs Section 06: Email Notification.
# PREFs Section 07: Upload Form Configuration.
# PREFs Section 08: Upload Restrictions.
# PREFs Section 09: Processing Uploads.
# PREFs Section 10: Post-Upload.
# PREFs Section 11: File-List Configuration.
# PREFs Section 12: Database Setup.
# PREFs Section Z: Misc Settings Not Usually Needed.
#
############################################################################
# PREFs Section 01: Debugging.
############################################################################
# The enable_debug PREF prints some debugging output in an HTML comment at
# the bottom of the page, if you pass "debug" as the query-string. And the
# show_errors_in_browser PREF causes any fatal errors to be printed right in
# the browser, in addition to in your server's error log. Enable both of
# these until you get FileChucker working properly, then disable them.
#
$PREF{enable_debug} = 'no';
$PREF{show_errors_in_browser} = 'yes';
# PREFs Section 02: Paths and Directories.
############################################################################
# Some servers seem to not set $ENV{DOCUMENT_ROOT} properly (in one case,
# for users who serve pages from their home directories), so we'll make
# our own version. Most of the time it should be set to the docroot,
# but if necessary you can adjust this here. The default value is:
#
# $PREF{DOCROOT} = $ENV{DOCUMENT_ROOT};
#
# IIS users will often need to set it like this:
#
# $PREF{DOCROOT} = 'c:\inetpub\wwwroot';
#
$PREF{DOCROOT} = $ENV{DOCUMENT_ROOT};
# PREFs Section 02: Paths and Directories.
############################################################################
# This is where the uploaded files will go. It must be world-readable
# and world-writable, aka "chmod a+rwx" or "chmod 0777".
#
# On most servers this will be in the DOCROOT, in which case we'll prepend
# your DOCROOT to whatever you set uploaded_files_dir to. If for some
# reason you want to specify it with an absolute path, or a path that's
# relative to the current directory instead of the DOCROOT, then set the
# _is_in_docroot PREF to no.
#
# And by default you should put the images (file/folder icons, logos, some
# rounded corners, etc, from filechucker-images.zip on the FileChucker web
# page) in the /upload/ directory, but you can adjust that too.
#
$PREF{uploaded_files_dir} = '/upload/files';
$PREF{uploaded_files_dir_is_in_docroot} = 'yes';
$PREF{path_to_filelist_images} = '/upload/';
# PREFs Section 02: Paths and Directories.
############################################################################
# If you set uploaded_files_dir to a path outside your webspace, then we
# won't be able to directly link to the files from your website, because
# they aren't in the DOCROOT. If you're doing something like manually
# moving the files to somewhere else within your DOCROOT afterwards, then
# enter that path here. Otherwise just leave this commented out. Note:
# don't include an ending slash on this.
#
#$PREF{uploaded_files_urlpath} = '';
# PREFs Section 02: Paths and Directories.
############################################################################
# This is where datafiles (which are temporary: only needed while a given
# upload is in progress) are stored. This must be world-readable and
# world-writable. By default, we set its _in_docroot PREF to 'no' because
# by default the data directory gets placed at the same location as the
# filechucker.cgi script itself, so we don't need to prepend the value of
# DOCROOT onto it; we can access it directly since it's in the same dir
# we're running in. The default settings are:
#
# $PREF{datadir} = 'fcdata';
# $PREF{datadir_is_in_docroot} = 'no';
#
# Alternatively you can set it with an absolute path, like this:
#
# $PREF{datadir} = '/var/www/mysite.com/cgi-bin/fcdata';
# $PREF{datadir_is_in_docroot} = 'no';
#
# Or this:
#
# $PREF{datadir} = 'c:\inetpub\wwwroot\cgi-bin\fcdata';
# $PREF{datadir_is_in_docroot} = 'no';
#
$PREF{datadir} = 'fcdata';
$PREF{datadir_is_in_docroot} = 'no';
# PREFs Section 02: Paths and Directories.
############################################################################
# The logfiles are just used during each upload, to keep track of how much
# data has been sent, how much time has elapsed, etc. They aren't used at
# all after an upload has completed, so you probably want them deleted right
# away. Note that these are different from the info-files which contain a
# permanent record of the upload including info like who uploaded what, the
# uploader's IP, date/time, etc.
#
$PREF{delete_logfiles_immediately} = 'yes';
# PREFs Section 02: Paths and Directories.
############################################################################
# If you want to access FileChucker at a short URL like yoursite.com/upload/
# instead of yoursite.com/cgi-bin/filechucker.cgi, then you can do the
# following:
#
# If you're using SSI (Apache and IIS both support this), then put the
# following line into /upload/index.shtml on your server:
#
#
#
# Or if your server runs PHP, you can put the following line into
# /upload/index.php on your server:
#
#
#
# Then set the 'here_' PREFs like this:
#
# $PREF{here_uploader} = '/upload/';
# $PREF{here_filelist} = '/upload/';
# ...
#
# Otherwise leave these set to $ENV{SCRIPT_NAME}.
#
# Note that in most cases these should all be set to the same value, i.e.
# unless you've actually set up multiple short URLs to point to the CGI
# script. And if you only set the single $PREF{here} value, then the
# others will automatically be set to that value.
#
$PREF{here} = $ENV{SCRIPT_NAME};
#$PREF{here_uploader} = $ENV{SCRIPT_NAME};
#$PREF{here_uploadcomplete} = $ENV{SCRIPT_NAME};
#$PREF{here_filelist} = $ENV{SCRIPT_NAME};
#$PREF{here_login} = $ENV{SCRIPT_NAME};
#$PREF{here_errorpage} = $ENV{SCRIPT_NAME};
# PREFs Section 03: Security.
############################################################################
# Password Protection, Option 1 of 4 (simple; no usernames):
#
# If you want to require just a password (without a username) for
# access to the uploader and/or the list of uploaded files, then you
# can set these hashes. Go to:
#
# yoursite.com/cgi-bin/filechucker.cgi?newpw
#
# ...enter the password you want to use into that page, and it
# will generate a "hash" of the password, which is a string that
# looks something like this:
#
# cdfc81932491375c34c842bcebc7dc15
#
# Copy and paste the hash into one of the following preferences.
# Then when you want to log in, enter the password, not the hash.
# (This is so that we don't store the actual password on disk, which
# would be very insecure.)
#
# We specify two possible user-levels (or "groups"): member and admin.
# (Actually, there are three, including "public" which obviously has no
# password.) If you want, you can use just one of them, and have a
# single password for both uploading and viewing the file-list. Or you
# can specify both, and set the "groups_allowed_to" preferences
# accordingly, so that only the admin can view the uploaded files. Or
# vice-versa. Or you could require no password to view the file-list,
# but require one to upload. Etc, etc. Just set the prefs accordingly.
#
# Note that the admin is automatically a "member" too, so someone
# with the admin password automatically has access to anything that
# requires the member password.
#
$PREF{member_password_hash} = '';
$PREF{admin_password_hash} = '1ba86cf7548z891f32db68c362c544b1';
# PREFs Section 03: Security.
############################################################################
# Password Protection, Option 2 of 4 (full-featured; unlimited usernames):
#
# If you need a full-featured login system (with unlimited usernames, each
# having its own password, and unlimited groups), instead of FileChucker's
# simple built-in password system which has just 2 passwords and no
# usernames, then you may want to use our UserBase application:
#
# http://encodable.com/userbase/
#
# FileChucker integrates fully with UserBase, and if you set the PREF
# "enable_userdirs" below, then each of your users will have their own
# private upload subdirectory.
#
# To use FileChucker with UserBase, you must configure FileChucker's
# database settings in PREFs Section 12.
#
# You must specify the URLs to UserBase on your server. Note that these
# are not full filesystem paths; they are within your server's DOCROOT.
# The default values are:
#
# $PREF{logout_url} = '/cgi-bin/userbase.cgi?logout';
# $PREF{login_url} = '/login/';
#
# If you don't have the nice short /login/ URL set up on your server
# (see UserBase homepage for instructions), then just set the login_url
# value to the full path to the userbase.cgi file.
#
$PREF{integrate_with_userbase} = 'no';
$PREF{logout_url} = '/cgi-bin/userbase.cgi?logout';
$PREF{userbase_login_error_title} = "Authentication Required";
$PREF{userbase_login_error_message} = "Please %%login_link%% first.";
# The rest of these must be set to the same values as in userbase.cgi:
$PREF{user_table_name} = 'ub_users_trl';
$PREF{group_table_name} = 'ub_groups_trl';
$PREF{login_url} = '/cgi-bin/userbase.cgi';
$PREF{max_username_length} = 30;
$PREF{max_groupname_length} = 30;
$PREF{max_hashedpw_length} = 50;
$PREF{public_group_name} = 'public';
$PREF{member_group_name} = 'member';
$PREF{admin_group_name} = 'admin';
$PREF{idle_timeout} = 0; # in seconds; zero to disable.
$PREF{enable_ip_address_restriction} = 'yes';
$PREF{force_ip_address_restriction} = 'no';
# PREFs Section 03: Security.
############################################################################
# Password Protection, Option 3 of 4 (use your site's existing login system):
#
# If your site already has a cookie-based login system, then you can set
# these PREFs to make FileChucker integrate with it. FileChucker will use
# the existence of the cookies specified here as confirmation that a user is
# logged in to your site. Note that this option is mutually exclusive with
# the integrate_with_userbase option.
#
$PREF{integrate_with_existing_login_system} = 'no';
$PREF{login_error_title} = "Error: not logged in";
$PREF{login_error_message} = qq`Perhaps you need to go home and log in first?`;
$PREF{member_username_cookie_name} = 'member_username';
$PREF{admin_username_cookie_name} = 'admin_username';
#$PREF{logout_url} = '/logout/';
#$PREF{login_url} = '/login/';
# PREFs Section 03: Security.
############################################################################
# (Pseudo-)Password Protection, Option 4 of 4 (automatic private directories):
#
# You can enable this serial_is_userdir option to get much of the benefit
# of usernames & passwords without actually having to use usernames or
# passwords. When configured this way, FileChucker will automatically put
# each new upload into a new unique private subdirectory, something like:
#
# yoursite.com/upload/?userdir=11832920981234098203458234098123
#
# This is primarily meant to facilitate single-use uploads, for instance
# where a person just wants to share one file one time; however by using
# the link provided at the end of the upload and in the notification email,
# the user can actually reuse the same uploads folder for as long as he wishes.
#
# In order to configure FileChucker this way, in addition to setting this
# serial_is_userdir PREF, you should also find & set the following:
#
# $PREF{keep_userdir_on_url} = 'yes';
# $PREF{enable_userdir_on_url} = 'yes';
# $PREF{enable_userdirs} = 'yes';
# $PREF{auto_create_userdirs} = 'yes';
# $PREF{groups_allowed_to_upload} = 'public';
# $PREF{groups_allowed_to_list_files} = 'public';
# $PREF{groups_allowed_to_download} = 'public';
# $PREF{groups_allowed_to_delete_items} = 'public';
# $PREF{hide_path_to_uploads_dir} = 'yes';
# $PREF{enable_subdirs} = 'no';
#
# $PREF{send_email_notifications} = 'yes';
# $PREF{email_notification_recipient_1} = 'webmaster@yoursite.com';
# $PREF{sender_email_address} = 'filechucker@yoursite.com';
# $PREF{email_subject} = 'New upload on yoursite.com';
#
# $PREF{formfield_01} = 'Sender Email Address:';
# $PREF{formfield_01_email} = 'yes';
#
# $PREF{formfield_02} = 'Recipient Email Address:';
# $PREF{formfield_02_email} = 'yes';
#
# If you'd rather not go through all the PREFs trying to find those, you
# may want to just set them in a separate PREFs file as explained at the
# top of the PREFs section.
#
$PREF{serial_is_userdir} = 'no';
# PREFs Section 03: Security.
############################################################################
# Whether you're using UserBase or FileChucker's built-in password system,
# the following "groups_allowed_to_*" PREFs control who can access what.
# Each item must be set to a comma-separated list of group names. If you're
# not using UserBase, then the only possible groupnames are public, member,
# and admin. Note that public includes member and admin (i.e. members and
# administrators are also members of the public), and member includes admin
# (i.e. administrators are also members).
#
# If you are customizing FileChucker by modifying its internal code, and you
# want to add your own restricted actions here, see the user_is_allowed_to()
# function, and search the script for calls to that function, to see how the
# system works.
#
$PREF{groups_allowed_to_upload} = 'public';
$PREF{groups_allowed_to_list_files} = 'public';
$PREF{groups_allowed_to_download} = 'public';
$PREF{groups_allowed_to_view_upload_info} = 'public';
$PREF{groups_allowed_to_move_items} = 'public';
$PREF{groups_allowed_to_delete_items} = 'public';
$PREF{groups_allowed_to_replace_existing_files} = 'public';
$PREF{groups_allowed_to_reprocess_existing_files} = 'public';
$PREF{groups_allowed_to_order_items} = 'public';
$PREF{groups_allowed_to_force_update_of_thumbs_cache} = 'public';
$PREF{groups_allowed_to_create_folders_during_upload} = 'public';
$PREF{groups_allowed_to_create_folders_thru_filelist} = 'public';
$PREF{groups_allowed_to_rotate_images} = 'public';
# PREFs Section 03: Security.
############################################################################
# Once you allow someone to download a file from your uploads area,
# they will know the path to all your uploads. If you don't want
# them to be able to see all the other files by just visiting that
# directory's address, you'll need to put a .htaccess file in that
# directory with the line "Options -Indexes" (without quotes).
# However, as long as they know the address, they can still try to
# guess filenames that might be in there. As an extra security
# precaution, you can set serialize_all_uploads, which adds a long
# pseudo-random number to each filename, making it virtually
# impossible that someone could guess the name of a file in the
# directory.
#
$PREF{serialize_all_uploads} = 'no';
# PREFs Section 03: Security.
############################################################################
# Choose whether the script should display a link to the list of
# uploaded files. Note that "members" includes "admins", and
# "strangers" includes everyone (i.e. members and admins too).
#
$PREF{show_link_to_uploads_for_strangers} = 'yes';
$PREF{show_link_to_uploads_for_members} = 'yes';
$PREF{show_link_to_uploads_for_admins} = 'yes';
# PREFs Section 03: Security.
############################################################################
# When an upload finishes, we display an "Upload Complete" page, which
# lists the names of the files that were uploaded, along with their
# sizes, and some other information. On this page, each filename is a
# link to download that file, unless you set these to 'no'.
#
$PREF{upload_complete_page_links_to_files_for_strangers}= 'yes';
$PREF{upload_complete_page_links_to_files_for_members} = 'yes';
$PREF{upload_complete_page_links_to_files_for_admins} = 'yes';
# PREFs Section 03: Security.
############################################################################
# Whether to display the login link in the footer-links at the bottom of
# the page. If you don't want to display it, then you log in by either
# trying to access a page you don't have access to (which will print the
# login link in the error message), or by passing ?login to the script.
# Of course if you're not configuring your FileChucker with any of the
# password PREFs then this is irrelevant.
#
$PREF{show_login_link} = 'yes';
# PREFs Section 03: Security.
############################################################################
# In various places -- the upload subdirectory drop-down box, the move-item
# page, etc -- we need to show the user a path to the uploaded files. The
# beginning of this path will be the value of your uploaded_files_dir if
# that's in your docroot, or else it'll be the value you set for
# uploaded_files_urlpath. But if you want that beginning part of the path
# to be hidden from your users, then enable this PREF. Note that the user
# can still see this part of the path whenever they actually download a
# file, since naturally we need to go through the whole path to get to the
# file.
#
$PREF{hide_path_to_uploads_dir} = 'no';
# PREFs Section 03: Security.
############################################################################
# FileChucker supports custom folder permissions, allowing you to specify
# which user-levels (public, member, or admin) have read-only (RO) or
# read-write (RW) access (or no access) on a per-folder basis. If you're
# also using UserBase, then you can create unlimited user-levels (i.e.
# groups) and you can also specify permissions per individual user.
#
# If you don't specify any permissions for a given folder, then it inherits
# the permissions from its parent folder; if no permissions have been set
# for a folder or its parents, then the default rights specified here take
# effect.
#
# The $PREF{permissions_required_to_view_permissions} setting allows you to
# control whether users can see what permission levels are set (only for
# folders that they can see). Only admins can set/change permissions,
# unless you are using UserBase and you have set the $PREF{enable_userdirs}
# setting, in which can you can allow users to adjust the permissions within
# their own userdir by setting the $PREF{users_can_change_perms_in_own_userdir}
# option. By default this only allows the user to adjust whether the generic
# "public" and "members" groups have access to their folders, because in many
# cases you would not want your users to be able to see the other groups and
# usernames in your system. But you can adjust this behavior as well using the
# users_changing_userdir_perms_can_see_other_groups/users settings.
#
# The $PREF{user_perms_override_group_perms_for_same_folder} setting (which
# only applies when using UserBase, since without UserBase there are no
# individual users, only groups aka user-levels) specifies whether user or
# group permissions have higher priority when both are set for the same
# folder. When both are set but at different levels, the perms closest to
# the folder in question are the ones that take effect. For example, given
# folders foo, bar, and baz with these permissions set:
#
# foo -> set to RO for user "bob"
# |--bar -> set to RW for group "sales" (where bob is a member)
# |--baz -> no perms set
#
# The effective permissions for bob are RO for foo, RW for bar, and RW for
# baz.
#
# Note that this feature requires a database, which you must configure
# in PREFs Section 12, and your database user must have these MySQL
# privileges: Select, Insert, Update, Delete, Create. Or if you want to
# manually create the table yourself, then the user does not need the Create
# privilege.
#
$PREF{enable_custom_folder_permissions} = 'no';
$PREF{perms_table_name} = 'folderpermstrl';
$PREF{default_folder_rights} = 'none'; # none, ro, rw; admins always have rw.
$PREF{permissions_required_to_view_permissions} = 'rw'; # none, ro, rw, or admin.
$PREF{user_perms_override_group_perms_for_same_folder} = 'yes'; # requires UserBase.
$PREF{users_can_change_perms_in_own_userdir} = 'yes'; # requires UserBase & $PREF{enable_userdirs}.
$PREF{users_changing_userdir_perms_can_see_other_groups}= 'no';
$PREF{users_changing_userdir_perms_can_see_other_users} = 'no';
# PREFs Section 03: Security.
############################################################################
# These should virtually always be 777; on a small number of servers you may
# be able to get away with using the less-permissive 755 instead.
#
$PREF{writable_dir_perms_as_string} = '0777'; # quotes required. default is '0777'.
$PREF{writable_dir_perms_as_octal} = 0777; # no quotes. default is 0777.
$PREF{writable_dir_perms_mask_as_octal} = 07777; # no quotes. default is 07777.
# PREFs Section 04: User-directories.
############################################################################
# Only allow each user to access their own upload directory. The user's
# directory is determined by the preferences you set below; it will either
# come from ?userdir=foo on the URL, or from a username cookie that's set
# by your site's existing login framework. If you don't want any kind of
# username-based directories, and you want all users to be able to upload
# to wherever they want, then don't set this. Finally note that even when
# this is set, administrators can still upload to and view any folder.
#
$PREF{enable_userdirs} = 'no';
$PREF{userdir_folder_name} = 'home';
$PREF{error_if_userdir_not_supplied} = 'no';
# PREFs Section 04: User-directories.
############################################################################
# If you're dropping FileChucker into an existing system with lots of
# users, you may not want to manually create a user subdirectory for each
# one. In that case you can enable this, and then anyone who visits with
# ?userdir=foo or with foo in their username cookie will cause the username
# directory to be created automatically.
#
$PREF{auto_create_userdirs} = 'yes';
# PREFs Section 04: User-directories.
############################################################################
# Enable ?userdir=username (or ?userdir=whatever) on the URL to automatically
# select the upload subdirectory. Note that this is probably insecure and
# you should use enable_userdir_from_cookie instead.
#
$PREF{enable_userdir_on_url} = 'no';
# PREFs Section 04: User-directories.
############################################################################
# If you're using enable_userdir_on_url, then you probably also want to set
# this keep_userdir_on_url option, so that when a user clicks on the various
# links like "Show Uploads," it keeps them inside their proper folder.
#
$PREF{keep_userdir_on_url} = 'no';
# PREFs Section 04: User-directories.
############################################################################
# If you want per-username upload subdirectories, and you already have some
# kind of login framework in place on your site that stores usernames in
# cookies, then you can use this to automatically choose the right subdir
# based on the value in the cookie. This means that each user will only
# be able to view and upload to his own subdirectory within your
# uploaded_files_dir.
#
$PREF{enable_userdir_from_cookie} = 'no';
$PREF{userdir_cookie_name} = 'username';
# PREFs Section 05: Subdirectories.
############################################################################
# Allow users to upload to subdirectories if they want.
#
$PREF{enable_subdirs} = 'yes';
# PREFs Section 05: Subdirectories.
############################################################################
# Allow users to create new subdirectories (but only within your
# uploaded_files_dir, of course). You can also choose to only
# display a single "New subdir" textbox, even when the user is
# uploading multiple files, so that all the files in that one
# upload session will go into the same new subdirectory.
#
$PREF{enable_manual_creation_of_new_subdirs_during_upload}= 'yes';
$PREF{only_allow_one_new_subdir_per_upload} = 'no';
$PREF{max_num_of_subdir_levels} = 5;
$PREF{max_length_of_new_subdir_names} = 25;
# PREFs Section 05: Subdirectories.
############################################################################
# FileChucker can automatically create a new subdirectory for each upload,
# and you can specify the name of this new subdirectory here. It can
# include values from the user's cookies, from the URL, from any extra
# formfields that you have configured (see PREFs Section 07), and from the
# current date/time.
#
# Note that you must also set the enable_subdirs option (above).
#
# To include variables from either the URL or from a cookie, use the format
# %URL{varname} or %COOKIE{cookiename}. To use values that the user types
# into your form fields, use the format %FIELD{shortname}. For example if
# you have $PREF{formfield_01_shortname} = 'company', then you can use
# %FIELD{company}.
#
# You can also use variables of the form %v to insert date/time values based
# on the standard date formatting variables; search the internet for the
# terms "unix man pages: date (1)" (or just run "man date" on any Unix
# system) for more information on the date format.
#
# Anything not preceded by a percent-sign will be passed straight through as
# literal text.
#
# For example, if you set:
#
# $PREF{automatic_new_subdir_name} = 'Job-%Y%m%d-%COOKIE{company}';
#
# ...and the user has a cookie called "company" set to "MyCo", and the date is
# say Feb 28 2006, then the new subdir will be named:
#
# Job-20060228-MyCo
#
# Finally note that to disable this, you must comment it out or set
# it to null ('').
#
$PREF{automatic_new_subdir_name} = '';
# PREFs Section 05: Subdirectories.
############################################################################
# If you want to enable subdirectories, but do not want your users to be
# able to see the list of subdirectories on the upload form, then you can
# disable this.
#
# Whether or not this drop-down is displayed, you can pass ?path=/some/subdir/
# on the URL to specify the destination directory for the uploaded files.
# If the drop-down is displayed, then this has the effect of selecting the
# specified path by default, but the user can still change it. If the drop-
# down is not displayed, then the path specified on the URL will be forced.
# Note that the $PREF{hide_path_to_uploads_dir} setting (PREFs Section 03)
# affects this option; if that setting is enabled, then the path specified on
# the URL must not include $PREF{uploaded_files_dir} on the front. And
# conversely, if $PREF{hide_path_to_uploads_dir} is disabled, then the path
# specified on the URL *must* include $PREF{uploaded_files_dir} on the front.
#
$PREF{display_dropdown_box_for_subdir_selection} = 'yes';
# PREFs Section 05: Subdirectories.
############################################################################
# A relatively frequent request is for the ability to allow uploads to
# subdirectories of your $PREF{uploaded_files_dir} folder, but not to
# that folder itself. This option enables that behavior.
#
$PREF{force_all_uploads_into_subdirectories} = 'no';
# PREFs Section 06: Email Notification.
############################################################################
# You can have the script send you an email whenever a new upload happens.
# It can be sent to as many recipients as you want. Most of the email PREFs
# are fairly self-explanatory, but here are a few notes: the sender address
# doesn't have to be a real address, but it DOES have to end with a real
# domain name. The smtp server is probably localhost or mail.yoursite.com,
# and we'll try both smtp and sendmail when trying to send an email. The
# email type can be either html or text, and the failure action can be
# either die_on_email_error or null, in which case we'll just ignore the
# error. Note that if you set it to die_on_email_error, then that means
# we can't fork the sending operation off into a separate process, since we
# have to wait to make sure it completes; this means that the upload takes
# longer from the user's perspective (if the upload was big and the email-
# sending operation takes a while). So once you've got FileChucker tested
# and are satisfied that the email portion works, you may want to NOT
# die on email error.
#
# SMTP Authentication is only needed if your mail server requires it. If
# so, you'll need to set the path to sendmail to either '/dev/null' or
# just ''.
#
# Note that if you want your users to be able to enter their own email
# address(es) on the upload form, to receive email notifications at those
# addresses, then you must configure an extra formfield for that, in
# PREFs Section 07.
#
# If you do enable an email-address formfield, you can choose to have the
# From: address on your notification emails be set to whatever address
# the user enters. To do that, set the $PREF{sender_email_address}
# option here to 'user_email_address'.
#
$PREF{send_email_notifications} = 'no';
$PREF{attach_uploaded_files_to_notification_emails} = 'no';
$PREF{email_notification_recipient_1} = 'me@my.com';
$PREF{sender_email_address} = 'filechucker@mysite.com';
$PREF{smtp_server} = 'localhost';
$PREF{smtp_port} = 25; # usually 25 or 587.
$PREF{smtp_auth_username} = '';
$PREF{smtp_auth_password} = '';
$PREF{path_to_sendmail} = '/usr/sbin/sendmail';
$PREF{email_type} = 'html';
$PREF{email_subject} = "New upload on mysite.com";
$PREF{email_failure_action} = 'die_on_email_error';
# PREFs Section 06: Email Notification.
############################################################################
# If you enable a custom text box as an email field (see PREFs Section 07),
# you can choose to have notification emails sent to the user-entered
# address(es), and whether those emails should contain the uploaded files
# as attachments. Note that this is separate from whether the site's
# webmaster receives attachments on his notification emails (see above).
#
$PREF{send_email_notifications_to_userEntered_addresses} = 'yes';
$PREF{attachments_on_notifications_to_userEntered_addresses} = 'no';
# PREFs Section 06: Email Notification.
############################################################################
# If you want totally customizable notification emails, use the options in
# this section. Here are some examples (these are for plaintext emails; be
# sure to add line-breaks
and/or paragraphs
if you're using HTML # emails): # # $PREF{admin_email_subject_for_new_uploads} = "New upload from: %uploader_hostname%"; # # $PREF{admin_notification_email_template} = qq` # # New upload received. Details: # # Date: %endtime_nice% # Uploader's IP: %uploader_ipaddress% # Total size: %totalsize_nice% # ... # # Files Uploaded: # # %filelist% # # `; # # # $PREF{user_email_subject_for_new_uploads} = "Upload confirmation from mysite.com"; # # $PREF{user_notification_email_template} = qq` # # Thanks for your upload! # ... # # `; # # The list of allowable variables includes all your formfield _shortname values # (see PREFs Section 07), plus these built-in variables: # # uploader_ipaddress uploader_hostname # totalsize_bytes totalsize_nice # userdir username # startetime starttime_nice # endetime endtime_nice # finalpath_local filelist # # The etime (epoch-time) variables %startetime% and %endetime% can also be # formatted into date variables in any format you'd like, by using this # syntax: # # %endetime--date--#Y-#m-#d, #I:#M #p% # # Search the internet for "unix man pages: date" (or just run the command # "man date" on any Unix system) for more information on the date format. # # The %filelist% variable is for the names of the files in this upload. # Each filename in the list is formatted based on the template in the # $PREF{admin_notification_email_filename_template} option or the # $PREF{user_notification_email_filename_template} option, and these # can include the variables filename, filesize, linktofile, realpath, # urlpath, localpath, filenum, and filecount. For example: # # $PREF{admin_notification_email_filename_template} = qq`File %filenum% of %filecount%:\n%filename% (%filesize%)\n%linktofile%\n\n`; # # Or, if you are using HTML-formatted emails: # # $PREF{admin_notification_email_filename_template} = qq`
File %filenum% of %filecount%:
%filename% (%filesize%)


Upload some files!
`; $PREF{outtro} = ''; $PREF{number_of_files_label} = 'Number of files to upload:'; # PREFs Section 07: Upload Form Configuration. ############################################################################ # If you're embedding FileChucker into an existing layout, then you probably # don't want FC to print out full HTML tags. So you can disable that here. # In that case you must also put the following lines into the section # of your website's header/template file: # # # # # Note that the CSS output may have conditional comments at the bottom that # you'll need to copy directly into the section of your site. # # If you are not going to use print_full_html_tags, then ideally you'll be # calling FileChucker from a file like /upload/index.shtml that contains # something pretty similar to this: # # # # # # ...where header.shtml and footer.shtml contain your site-wide standard # HTML code that each page is wrapped in. Or, if your header/footer are # in PHP, then your /upload/index.php might look like this: # # virtual("/header.php"); ?> # virtual("/cgi-bin/filechucker.cgi?" + $_SERVER['QUERY_STRING']); ?> # virtual("/footer.php"); ?> # # However, if you are on a brain-dead server (which is to say, IIS6+) which # does not support any decent way to call a CGI script that includes the # proper server environment variables, and your server does not have PHP # installed, and you still want to include a standard header/footer with # FileChucker, you can set default_sitewide_header_file and _footer_file # here. The contents of these files will then be included in FileChucker's # output. Note that no server-side processing (PHP, SSI, etc) will be done # on the contents of these files; however you can specify a title within # the header file by inserting the string %%title%% (for example, as in #