Textpattern CMS

#1 2016-09-22 17:05:18

ande

Member

Registered: 2007-01-21

Posts: 25

ign_password_protect: Modified the plugin myself, problems with 4.6.0

I’ve used ign_password_protect for quite some time now.

TL;DR: I think the plugin provides somehow wrong credentials for the database access although TXP 4.6.0 works fine in the rest of the installation, and it worked in 4.5.7

Because it had been the only option then, I have modified the plugin to make it work here.

The plugin uses the (I thought) generic function safe_row() but I get this error:

Ein Fehler trat auf beim Laden des Plugins: ign_password_protect -> Warning: mysql_real_escape_string(): Access denied for user 'web14'@'localhost' (using password: NO) on line 119
Ein Fehler trat auf beim Laden des Plugins: ign_password_protect -> Warning: mysql_real_escape_string(): A link to the server could not be established on line 119

In English: Access denied because obviously we have the wrong username “web14” – according to config.php the correct credentials are:

$txpcfg['db'] = 'c4ggtm'; 
$txpcfg['user'] = 'c4ggtm';
$txpcfg['pass'] = 'hahayouthinkiwriteithere?';
$txpcfg['host'] = 'localhost';

“web14” is the correct name of the apache user acting here.

Where does the function safe_row() gets the database connection credentials from? I guess some object / class has not been initialized properly or a global has been renamed – while it works for the rest of the installation.

What I am trying to do is to access a table “adressen” that is part of the database “c4ggtm” in order to validate a hash against that database.

Any help welcome!

Andreas

Last edited by ande (2016-09-22 17:11:25)

#2 2016-09-22 20:53:25

Bloke

Developer

From: Leeds, UK

Registered: 2006-01-29

Posts: 11,269

Website GitHub

Re: ign_password_protect: Modified the plugin myself, problems with 4.6.0

ande wrote #301688:

mysql_real_escape_string(): Access denied

I’ve not looked at the plugin for a while but this isn’t the first report of such behaviour we’ve had. Here’s what I think is going on:

• In Txp 4.6.0 we moved from using mysql_*() to mysqli_*() (note the ‘i’) functions as a stop-gap on our way towards PDO.
• Our DB connection object is initiated via mysqli.
• Pretty much all mysqli_*() calls require $DB->link to be passed in as the first parameter. mysql_*() calls did not; they relied on the global connection.
• Thus, any plugin that uses an old-skool mysql_*() call does not automatically have a connection to the database because the global link is missing: it’s now wrapped up in the $DB object. Hence, permission denied.

Any plugins that exclusively use the core’s safe_*() or get*() calls are immune to any issues. There are, however, a few PHP functions that plugin authors use directly, due to gaps in our API: mysql_real_escape_string, mysql_get_server_info and mysql_error. To fix all three — and others — just do this:

1. In the plugin function that surrounds the mysql_*() call, ensure there is a global $DB; line somewhere near the top of the function.
2. Change the call name by adding an i after the mysql.
3. Add $DB->link as the first parameter to that call.
4. Repeat for all places where mysql_*() functions are used.

tl;dr: convert:

mysql_real_escape_string();

to:

global $DB;
...
mysqli_real_escape_string($DB->link);

and you’ll be on your way.

---

The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp