I would *NOT* put the user/password information anywhere the user might get at it. Because, unless you're using SSL and you trust your users (and, let's face it, not really even then, because people will mess up sooner or later, no matter how well-intentioned), you're just giving away crucial security information. Switching to POST or cookies just puts a little lace doily over the information, and doesn't really provide any extra level of security.

A first step would be to develop a unique identifier for each database connection, and have *that* information passed around; as long as you can figure out the user/pass combination for each identifier, you're golden, and you can keep the user/pass information on the server side.

Even this doesn't make me fully happy, but what I'd think about is storing a list of database names and passwords (along with identifiers for each) in as secure a location as possible, and make sure only your script can access that list. You can use a DBMS for this, no problem, because you can establish multiple DBI connections in one script. Then, on each time the script runs, you get the connection's identifier (which could now be in the URL, or stored in a cookie ... the ID, without the user/pass, is less useful to crackers).

Then use the ID to figure out which database the user needs access to. You then fetch, from your 'master' user/pwd list, the relevant information and establish a connection with that info.

That's just off the top of my head, though. I'd want to let this idea simmer for a while (and allow other Monks to poke and prod at it), because I don't like the idea of putting all the goodies in one basket either.

As to the second question: since every database handles admin tasks differently, probably not. At least I can't think of one off the top of my head. I'd do a search on CPAN, putting in the names of various DBMSes (the ones you use, obviously =) and see what pops up. I do know that there's a pretty useful tool called phpMyAdmin written in (of course) PHP and originally designed to allow you to administer a MySQL database over an HTTP interface. I don't know if anybody's ported that to Perl yet, or whether it's been extended to other DBMSes yet.

HTH, and good luck! 

perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); 
+$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth
+er_name\n"'

[download]

In reply to Re: User/Password Passing for a DB by arturo
in thread User/Password Passing for a DB by kbradford

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.