PhotoCatalog Restructuring
Loren M. Lang
follows:
photocatalog/
bin/ - All non-web-based Perl scripts
...
twitter.pl - Fetch Twitter updates
updatelocation.pl - Fetch Location updates
conf/ - All configurations (see below)
default.xml - Default configuration
icons/ - Logos, Symbols, Placemarks, etc.
images/ - Uploaded images
lib/ - Extra modules/plugins
Common.pm
Facebook.pm
tmp/
www/ - Public facing Website
index.cgi - Default map/front page
live.cgi - Perl script to generate live.kml dynamically
admin/ - Private administration Website
.htaccess (contains directives to Apache to require
HTTP authentication for accessing files in dir)
config.cgi - Main configuration page
upload.cgi - Update images/location data
Rationale: First, only icons, images, and www need to be visible over
Apache. By keeping www scripts distinct from bin, it will help keep the
web component an add-on and not a requirement of PhotoCatalog. The
configuration available over the web is simply a feature as the XML file
can always be edited manually, and Photos can be added and sorted
without visiting a website. Also, it keeps the bin scripts outside of
the URL space so malicious users can't try to abuse them. Also, by
keeping images outside the www directory, it's simply to have ExecCGI
only enabled under the www directory tree. For extra security, only
images needs to be writable by Apache and that directory will have
ExecCGI disabled (remember OSCommerce?). Also, more sensitive files
like the XML configuration files that might contain passwords or API
keys will be hidden. This will also lead to a cleaner top level
direcory, but it does make the Apache configuration a little more
complicated. Users will need to add alias to Apache for images/icons or
make symbolic links. They also could just move the folders into the www
folder and update the XML configuration file to point there instead of
it's default location.
A related change to this is a method for supporting multiple
configurations. In the above proposal, I've moved the default
configuration file to conf/default.xml. I also propose adding a
command-line option to all scripts like -config name which will cause it
to load an alternate configuration file. If name has a slash, then it
will be interpreted relative to the current directory, unless it begins
with a slash, in which case it will be an absolute path. If name does
not contain a slash, then it will look under photocatalog/conf/name.xml
if -config name is specified. A further refinement to this will be to
have the Perl CGI scripts autodetect the configuration name based of the
requested URL. Once example might be to have a DNS wildcard like
*.example.org where the first DNS component is taken as the name of the
configuration file in the above example. What do you think?
--
Loren M. Lang
lor...@north-winds.org
http://www.north-winds.org/
Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc
Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B