This leads me to ask: Am I asking the wrong question?I don't see how CGI should come into this at all. I expect this to be something that an admin (or me) would run from the shell prompt - I don't intend for it to be available on a web page or anything - the section:
use DBIx::Password;
my $filepath = $INC{"DBIx/Password.pm"};
Is only there to make sure that the correct version of the file Password.pm is used (if there is more than one for some odd reason). Should I be trying to solve this problem some other way perhaps? | [reply]
[d/l] |
No, writing a script utilizing a module makes absolute sense. After perusing DBIx::Password, I can see why you find it a pain. The module, when built, constructs a list of users, passwords, DBI drivers, etc. and modifies its own sourcecode, writing that data out to $virtual1, but after that file has been built, it's up to you to add new users, delete old ones from it. I suppose it's written this way because adding database users is a relatively uncommon activity, or at least it ought to be. In fact, why in the world are you changing database users on a regular basis? A good DB design does not require this. Rather, you should have general categories to which new users can be added. For example, you might have a three tier division, with, say 'administrator', 'trusted_user', 'guest'. When you get a new client you simply add them to the 'trusted_user' or 'guest' categories, just as you would to a *nix group. If they're sharing the same database, there's no reason for different passwords. <Update> atcroft pointed out in the CB that you may be allowing customers to create their own tables, for which multiple separate accounts would be useful. In this case, I would strongly recommend moving away from DBIx::Password and looking at a solution that separates your data (username/password strings) from your code. </Update>
That said, it sounds like what you want to do is to read the source for the module and rewrite it with new contents in an automated fashion. So, take a look at open, close, and look at some examples for reading contents from filehandles. As to specifying user options, look at Getopt::Std and Getopt::Long.
| [reply]
[d/l] |
Should I be trying to solve this problem some other way perhaps?
Yes. Don't store passwords in a Perl module. Put data in separate files, that aren't parsed by Perl. You could choose to use a database (which is quite easy to do in Perl), or a plain text file (a bit harder (even though most beginners seem to think plain text files are easy)) for your password storing.
Maybe I'm not understanding what your Password.pm does correctly.
Update - Nevermind me. I thought Vladinator was storing passwords in a module. "I know nothing about Perl" made me think he was a newbie that ill-named his module (You don't wanna know how many people store data in modules in the DBIx namespace, not realising that it is for DBI extensions). I didn't know about DBIx::Password on CPAN.
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.
| [reply] |
I expect this to be something that an admin (or me) would run from the shell prompt
No reason not to validate the input. It's a good habit to get into even if your granting full privilledges to the user (and always question if this is neccessary, least privilledge is good, blah blah blah) .
And yes, if you're wondering, this post is just a thinly veiled attempt to cover up the fact that I didn't read all of your original post and just gave a carbon copy answer (it's still good advice though :).
Anyways, have a good one :)
| [reply] |