1

Possible Duplicate:
Global or Singleton for database connection?

I have registered globals off. I make a connection to my database and save it in $db. In a function, I declare it global. I know that makes my variable global, so I can access it with $GLOBALS even after the function returns.

Did I just expose my connection to a security threat? Do I need to pass it as a parameter each time?

Community
  • 1
  • 1
phpmeh
  • 1,752
  • 2
  • 22
  • 41
  • 2
    Globals are not a threat to security, only to maintenance and analysis. – webbiedave Dec 02 '11 at 22:32
  • Indeed, the security scaremongering is a misattribution to good old register_globals. Likewise the single database connection global is typically the most minor coding issue. – mario Dec 02 '11 at 22:48

3 Answers3

3

Design-wise, there are better practices than having a global connection, but I can't see any security threats coming from this.

Pekka
  • 442,112
  • 142
  • 972
  • 1,088
  • Glad to see a confirmation on this. I see people stating the `$GLOBALS` and `Singletons` are bad, but they can never elaborate on why, I suppose they *could* be bad if setup wrong, but for a database connection, I fail to see how it is a security issue. – Jim Dec 02 '11 at 22:30
  • Singleton is bad for Unit testing. ^) –  Dec 02 '11 at 22:32
  • @altrange, in what way? If you have an article on it somewhere, or can elaborate I would appreciate it :) – Jim Dec 02 '11 at 22:34
  • @Brad here is an answer with some links to in-depth resources: [Unit testing with singletons](http://stackoverflow.com/q/2085953) – Pekka Dec 02 '11 at 22:34
  • Ok. But the idea is that phpunit (for example) use global bootstraping. So thats why all the test cases use the same singleton objects. Their states are changed globally and we can get unexpected results. –  Dec 02 '11 at 22:37
  • Thanks for the Pekka, and good to know. Have not really messed with the Unit Tests, should probably dive into that sometime soon. – Jim Dec 02 '11 at 22:43
  • 3
    @Brad Globals and Singletons are bad because they lead to [Hard to Maintain, Fragile and Non-Reusable code](http://www.objectmentor.com/resources/articles/oodmetrc.pdf). – Gordon Dec 03 '11 at 18:38
0

A better practice is to create a php include file which uses something like this:

// this is the address to the mySQL host
// all queries will utilize this variable for connection so changing can
// be done in one stop fashion

// the following defines
define('DB_HOST', '127.0.0.1');
define('DB_USER', 'a_username');
define('DB_PASSWORD', 'thepassword');
define('DB_DBASE', 'databasename');

Then create a function that tries to open a database link and returns the link if it succeeds. Then you can just call this one function all throughout your code using an include() without having to mess with globals or having them be actual variables etc.

R

Ross
  • 1,639
  • 1
  • 18
  • 22
  • 2
    I think storing the USER/PASSWORD in a constant is a bad idea, simply because you do not need it as a constant, you just need to give it to your database connection function or object. Storing as a content just seems dirty to me for some reason. Not going to -1 it, as I do not think it is "bad practice" just my opinion on it. I generally store them in an array in the config file and then destroy the array after instantiating the database connection. – Jim Dec 02 '11 at 22:32
  • I've always heard to store the password in a file that wasn't accessible to the general public, such as /home – phpmeh Dec 03 '11 at 05:08
0

Usually no. Sometimes db object is a "star object" and uses as Singleton.