PHP OOP dilemma: how to keep a database connection 'within' a class object?

Question

And here i am again! ;)

Im developing (well, im still in planning phase) a web-app where i would give to other developer the possibility to write theyr own plugins/modules (in the way of CMS does, drupal, joomla, etc).

My problem is that i have to force the developers to use the methods i wrote for interact with databases, for many reasons (data integrity first). I dont need primarly to keep secret the database structure, but if it is possible too, is appreciate.

So, in short, my goal is:

1. Keep 'protected' and not accessible from outside my classes the database connection;
2. If possible (but should be a consequence of point 1) keep secret the real database structure;

The plugins/modules behavior will be implemented like the Drupal hooks.

So, an short example of my current situation:

<?php
    // File dbclass.php
class DbHandler{
    /*
    * As simply as i could ;)
    */
    private $dbLink;
    public function __construct(){
        $this->dbLink = pg_connect("host=127.0.0.1 user=myuser password=mypassword dbname=mydatabase");
    }
    public function __destruct(){
        pg_close($this->dbLink);
        unset($this->dbLink);
    }
}
?>

and the module call:

<?php
// An general situation
require('dbclass.php');
/*
* The DbHandler consctruct function open a database connection.
*/
$init = new DbHandler();
/*
* [..i'll do something here..]
*/
/*
* Lets say this is inside a function/hook of an enabled module;
* This is the behavior i want to avoid!
* How to keep the database connection 'within' my
* DbHandler object's instance?
* p.s: in real life i do use prepared stmt
*/
$qrUsers = pg_query('SELECT * FROM users');
if(pg_num_rows($qrUsers) != 0){
    echo '<h2>Query success!</h2>';
    //do something
}else{
    echo '<h2>Query Fail!</h2>';
}
//Actual Output: Query Success! [...]
//Desidered output: Warning: pg_query() [function.pg-query]: No PostgreSQL link opened yet in /var/www-lighttpd/dbtest.php on line xx Query Fail!
?>

I want that if the developer try to execute directly a query, it will fail, and in the example i posted, he is forced to use a method like (for example)

$users = new User();
$users -> get_all();

Im running on postgresql, but i suppose the problem is the same on Mysql.

As far as i thought, the only way i can do that is to close the connection before call all the modules hooks, and then reopen and reclose it every time a hooks need to CRUD the database. But i really dislike this solution, wont be efficient.

If someone have betters ideas, please share them with me!

p.s: my english is poor, i hope the question is clear.

EDIT: the Oddthinking solution seem to be the best for me: the opening and immediately closing the ghost connection will prevent every next pg_* or mysql_* function call. This solution, in couple with renaming the pg_* or mysql_* functions with runkit / apd with custom names will (i think) definitely avoid any uncontrolled access to the DB by the modules/plugins.

Answer 1

Maybe you've heard of the decorator pattern, which might suit your needs. It's idea is to actually create a proxy instance of your database object which behaves exactly like your real database. Therefore, your real database is hidden to others and only your decorater object knows where to find the real database.

Answer 2

It's a bit of a hack, but:

Immediately after you do your pg_connect call, you could call pg_connect with some dud parameters. It will fail, but see if it also overrides the default connection to prevent others from using it in pg_query..

EDIT: It turns out (see comments) that calling pg_connect with dud parameters does NOT override the default connection.

Here is Plan B (untested):

$this->dbLink = pg_connect("host=127.0.0.1 user=myuser password=mypassword dbname=mydatabase");
$junkConnection = pg_connect("host=127.0.0.1 user=myuser password=mypassword dbname=mydatabase");
pg_close($junkConnection);

This creates a second connection to the database, but immediately closes it. I seriously doubt that would leave the default parameters reverting to the first connection.

Answer 3

Hm, maybe you could solve this at the DB-level?

You could have two user accounts on the db. One that has proper priviliges called app-main or something, that you connect with—and one that has zero priviliges called app-plugin. Then, you could call your plugin like this:

pg_query("SET ROLE app-plugin;"); //precaution--use low-privilege-user
$plugin->doStuff();
pg_query("SET ROLE NONE;"); //Reset role back to default

This would have the priviliges lowered to that of the app-plugin-user for the current session. Of course, the plugin could call "SET ROLE NONE;" to raise priviliges again itself, so it's not "safe". It would just be like a precaution. But the connection would at least be kept alive and normal queries would fail. (Of course if the plugin gets called like 50 times during a session it might impact performance.. who knows?)

Anyway, I have never tried this mysqlf so I don't know anything about this, really..

Docs:
http://www.postgresql.org/docs/8.4/interactive/sql-set-role.html

Answer 4

I might be missing something but as long as users can read your code they can copy & paste the information needed to make their own connection. Are you really allowing users to connect to your database?!

Lets say this is inside a function/hook of an enabled module;

This is the behavior i want to avoid!

SELECT * ...

This is not your problem. My guess is users are going to host your app in their own enviroment/database(s), therefor they are taking damage of bad practice when you provided better alternatives.

Answer 5

Two options spring to mind:

1. Enforce this in documentation/standards instead of code (it sounds like this is insufficient for your case?)

2. Use PDO pgsql instead of the pg_* API.

Hacks like opening/closing dummy DB connections will work but I would consider this as a last resort.

It sounds like you want to assure the quality of your system and its plug-ins. I think these hacks defeat that purpose. No doubt I am making some assumptions here, but generally speaking, I think the best way is to offer solid examples/standards to your plug-in writers and good documentation. If you will be hosting an authoritative repository for the plug-ins, then you could also scan their code for violations like this and suggest that the maintainers fix them.