One other thing that's bugging me about this is how to provide the
config data to the scripts at runtime in a web environment.
If this were a one-time script it would be simple to hard-code them in,
but we expect to be able to re-use the package for multiple client
environments.
The constraints of a web-environment prevent me from creating a file in
the DOCUMENT_ROOT directory to hold the username,pass,database data (in
say a YAML format file) although nothing is preventing me from using the
form data to create a tmpfile and then sending that file to the user as
a download with instructions on where to place it.
Or, alternatively, at install time, I could have a subscriber_config
executable script set up such that it creates a Subscriber::Config.pm
file along the lines of how CPAN's config works (possibly)... again I'm
up against the constraints of which directories Apache will have access
to when serving the content.
it's easy enough to create an .htsub_config file in DOCUMENT_ROOT and
ensure that .htaccess or /etc/httpd/conf/httpd.conf has something along
the lines of:
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
that would prevent the contents of the file form being served to
end-users but still allow access to them from the scripts being run on
the server.
But I'll need some way to generate the file (either from the command
line at install time, or from the web at setup/configure time), and also
to parse it at script-runtime so that I can populate Subscriber::DB with
the access information.
a pretty nest of thorns to step carefully through, no matter what. *sigh* :)
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
