I would strongly recommend decoupling the data (in this case your login info) from the code. Rather than hardcoding this in, have the module use values specified in a separate configuration file. See Config::Easy or a similar module for some examples.
As for the location of the config file, it is definitely more maintainable to place it outside of the perl hierarchy. Consider what happens if another program wants to use your module for a different data source.
Your greatest code re-use and ease of maintenance options will be to provide methods in the package which can accept either a filename or a hash of configuration options from the calling program. This abstracts the specific application (and application specific info like the database logins) from the module ... which is the whole point of writing a module.
Oh yeah, and the permissions on the config file will depend on how the program is run. If only one user needs to run it, 400 is good. If you can restrict it to a single unix group, then 440.
Updated with clarifying example skeletons of the methods:
sub readConfig { my $configfile = shift or die "No config file supplied"; # Read in the config file and set module-wide options # NB. I don't recommend "do" for this, as config files # shouldn't be able to contain executable code (IMHO) . . . } sub setConfig { my %opts = shift or die "No config options supplied"; # Set module-wide config based upon passed options . . . }
In reply to Re: directory and file access for modules containing sensitive information
by idsfa
in thread directory and file access for modules containing sensitive information
by silent11
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |