I'm trying to connect to a mySQL database at http://bluesql.net, but when I try to connect, it gives this error:
Connect Error (2000) mysqlnd cannot connect to MySQL 4.1+ using old authentication
I've looked into this, and it has to do with some old password scheme used before MySQL 4.1. Newer versions have the option to use old passwords, which I've read may cause this problem.
I'm running php 5.3, and connecting with mySQLi (new mysqli(...)). I'm hoping I can do something in the code to connect to the DB at bluesql.net - clearly I don't control how their database is set up. Downgrading php versions isn't an option.
Anyone have any ideas?
edit: This only applies if you are in control of the MySQL server... if you're not take a look at Mysql password hashing method old vs new
First check with the SQL query
SHOW VARIABLES LIKE 'old_passwords'
(in the MySQL command line client, HeidiSQL or whatever front end you like) whether the server is set to use the old password schema by default. If this returns old_passwords,Off you just happen to have old password entries in the user table. The MySQL server will use the old authentication routine for these accounts. You can simply set a new password for the account and the new routine will be used.
You can check which routine will be used by taking a look at the mysql.user table (with an account that has access to that table)
SELECT `User`, `Host`, Length(`Password`) FROM mysql.user
This will return 16 for accounts with old passwords and 41 for accounts with new passwords (and 0 for accounts with no password at all, you might want to take care of those as well).
Either use the user management tools of the MySQL front end (if there are any) or
SET PASSWORD FOR 'User'#'Host'=PASSWORD('yourpassword');
FLUSH Privileges;
(replace User and Host with the values you got from the previous query.) Then check the length of the password again. It should be 41 now and your client (e.g. mysqlnd) should be able to connect to the server.
see also the MySQL documentation:
* http://dev.mysql.com/doc/refman/5.0/en/old-client.html
* http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html
* http://dev.mysql.com/doc/refman/5.0/en/set-password.html
If you do not have control of the server
I just had this issue, and was able to work around it.
First, connect to the MySQL database with an older client that doesn't mind old_passwords. Connect using the user that your script will be using.
Run these queries:
SET SESSION old_passwords=FALSE;
SET PASSWORD = PASSWORD('[your password]');
In your PHP script, change your mysql_connect function to include the client flag 1:
define('CLIENT_LONG_PASSWORD', 1);
mysql_connect('[your server]', '[your username]', '[your password]', false, CLIENT_LONG_PASSWORD);
This allowed me to connect successfully.
Edit: as per Garland Pope's comment, it may not be necessary to set CLIENT_LONG_PASSWORD manually any more in your PHP code as of PHP 5.4!
Edit: courtesy of Antonio Bonifati, a PHP script to run the queries for you:
<?php const DB = [ 'host' => '...', # localhost may not work on some hosting
'user' => '...',
'pwd' => '...', ];
if (!mysql_connect(DB['host'], DB['user'], DB['pwd'])) {
die(mysql_error());
} if (!mysql_query($query = 'SET SESSION old_passwords=FALSE')) {
die($query);
} if (!mysql_query($query = "SET PASSWORD = PASSWORD('" . DB['pwd'] . "')")) {
die($query);
}
echo "Excellent, mysqli will now work";
?>
you can do these line on your mysql query browser or something
SET old_passwords = 0;
UPDATE mysql.user SET Password = PASSWORD('testpass') WHERE User = 'testuser' limit 1;
SELECT LENGTH(Password) FROM mysql.user WHERE User = 'testuser';
FLUSH PRIVILEGES;
note:your username and password
after that it should able to work. I just solved mine too
On OSX, I used MacPorts to address the same problem when connecting to my siteground database. Siteground appears to be using 5.0.77mm0.1-log, but creating a new user account didn't fix the problem. This is what did
sudo port install php5-mysql -mysqlnd +mysql5
This downgrades the mysql driver that php will use.
Had the same issue, but executing the queries alone will not help. To fix this I did the following,
Set old_passwords=0 in my.cnf file
Restart mysql
Login to mysql as root user
Execute FLUSH PRIVILEGES;
If you do not have Administrator access to the MySQL Server configuration (i.e. you are using a hosting service), then there are 2 options to get this to work:
1) Request that the old_passwords option be set to false on the MySQL server
2) Downgrade PHP to 5.2.2 until option 1 occurs.
From what I've been able to find, the issue seems to be with how the MySQL account passwords are stored and if the 'old_passwords' setting is set to true. This causes a compatibility issue between MySQL and newer versions of PHP (5.3+) where PHP attempts to connect using a 41-character hash but the MySQL server is still storing account passwords using a 16-character hash.
This incompatibility was brought about by the changing of the hashing method used in MySQL 4.1 which allows for both short and long hash lengths (Scenario 2 on this page from the MySQL site: http://dev.mysql.com/doc/refman/5.5/en/password-hashing.html) and the inclusion of the MySQL Native Driver in PHP 5.3 (backwards compatibility issue documented on bullet 7 of this page from the PHP documentation: http://www.php.net/manual/en/migration53.incompatible.php).
IF,
You are using a shared hosting, and don't have root access.
you are getting the said error while connecting to a remote database ie: not localhost.
and your using Xampp.
and the code is running fine on live server, but the issue is only on your development machine running xampp.
Then,
It is highly recommended that you install xampp 1.7.0 . Download Link
Note: This is not a solution to the above problem, but a FIX which would allow you to continue with your development.
Related
I have a LAMP stack, and I thought it might be nice to use the MySQL configuration file to allow PDO to connect to the MySQL database without the need to place DB credentials within our code structure
So I created a group in /etc/my.cnf.d/gggg.cnf
[clientGggg]
user=uuuu
password=pppp
database=dddd
and can now connect to the DB through the command line with mysql --defaults-group-suffix=gggg
I then tried to create a test DB connection in PHP with
$db = new PDO("mysql", null, null, [PDO::MYSQL_ATTR_READ_DEFAULT_GROUP => 'gggg']);
but I received the error
Undefined constant PDO::MYSQL_ATTR_READ_DEFAULT_GROUP
Checking the PDO docs for this attribute reveals the following:
PDO::MYSQL_ATTR_READ_DEFAULT_GROUP (int)
Read options from the named group from my.cnf or the file specified with MYSQL_READ_DEFAULT_FILE. This option is not available if mysqlnd is used, because mysqlnd does not read the mysql configuration files.
and checking my phpinfo(); reveals I am indeed using mysqlnd
Why is this limitation in place? Is there a workaround? Or am I doomed to write/load my credentials into PHP?
What I'm trying to achieve is allow connection to MySQL server without defining password in PDO connection, instead of it I would like to define it in MySQL configuration.
I already created file /etc/mysql/conf.d/nopass.cnf with content:
[client]
host = localhost
user = someuser
password = somepass
socket = /var/run/mysqld/mysqld.sock
When connecting from shell it works as expected:
$ mysql -u someuser
mysql>
However, I'm not able to connect via PHP:
new PDO('mysql:host=127.0.0.1:3306;charset=utf8;dbname=somedb', 'someuser');
new PDO('mysql:host=127.0.0.1:3306;charset=utf8;dbname=somedb', 'someuser', null);
new PDO('mysql:host=127.0.0.1:3306;charset=utf8;dbname=somedb', 'someuser', );
In each case I receive error
PDOException: SQLSTATE[HY000] [1045] Access denied for user 'someuser'#'localhost' (using password: NO)
It works if I set correct password
new PDO('mysql:host=127.0.0.1:3306;charset=utf8;dbname=somedb', 'someuser', 'somepassword');
Is it possible to make this work?
As far as my testing has gone, PDO requires that something is provided in the password field so no matter what config setup you're using it will try to use its own syntax. If there is no password, then the password field should be set to an empty string i.e. '' and it submits that empty string as your password. The short answer is, AFAIK it's not possible to do what you're trying.
If your primary concern is having a password revealed due to someone finding a way to snoop around your PHP files, having it placed in a client config is a good method to try to circumvent that but there are native PHP methods that can also hide the sensitive information from potential security breaches stemming from leaked PHP file contents.
I answered a similar question not too long ago that talks about the three main recommendations I'd make regarding PHP security for SQL passwords here: Set up PDO connection without password which mostly includes moving the php script outside your webdata directory as well as protecting php files from direct access even if accessed by using redirects to hide their existence and having code that returns a 404 error if the files themselves are directly accessed. Also I'd suggest making PHP-exclusive accounts that have very limited access scopes so in case someone does find a way to inject sql, they won't be able to do or see much. For examples of what I'm talking about, feel free to follow the link to read up.
It seems nobody had this problem yet.... With db2_connect I found docs that decrible how to load a default library list (*LIBL) on connection but with PDO nothing!
I'd like to perform statements without specifing always the library name in front of file name. I already created a JOB DESCRIPTION to load the libraries, and when I log in with the PC5250 emulator those library are online.
But if I run a query with PDO without specifying the library name following is returned:
Error executing sth in testGet for AS400 SQLSTATE[42S02]:
Base table or view not found: 0
[IBM][System i Access ODBC Driver][DB2 for i5/OS]SQL0204 -
TESTFILE in WEB type *FILE not found.
(SQLPrepare[0] at ext\pdo_odbc\odbc_driver.c:206)
To use the library list, you will need to make sure your connection attributes specify system naming, and I would avoid setting a current schema.
Without much knowledge of PHP + PDO, the stackoveflow tag wiki gives a good introduction. Check that PDO is configured for proper settings for DB2 for i, not LUW or z. Likewise check db2_connect settings. (Why are you using that, instead of straight ODBC?)
I know it's been awhile since you posted but I came across some info on how to do library lists using the PDO driver... see http://yips.idevcloud.com/wiki/index.php/XMLSERVICE/PHPPDOChangeLog.
So for example you could do something like this:
$options = [
PDO::ATTR_PERSISTENT => true,
PDO::ATTR_AUTOCOMMIT => true,
PDO::I5_ATTR_DBC_SYS_NAMING => true,
PDO::I5_ATTR_DBC_LIBL => "LIB1 LIB2 LIB3",
];
$db = new PDO("ibm:SYSTEM", "user", "password", $options);
Keep in mind this will probably require a recent Zend Server (since Dec 2014). I know the latest stuff is in the new ZS 8.5 but I'm not sure about older releases.
You might also be able to leave off the library list option - in my limited testing this appears to let it use the library list from the job description. I'm not sure about the current library and YMMV but I'd be curious to hear back if it works for you or not.
Also for what it's worth an email address for the official maintainer is listed on http://pecl.php.net/package/PDO_IBM. Questions could also be sent to the WEB400 mailing list (http://lists.midrange.com/mailman/listinfo/web400), I think people who are involved in the development of the pdo_ibm driver are on there as well.
If you're talking about these docs, then that is if you're using PDO_IBM on IBM i. I don't think those settings are supported on any other platform. From your error message, it seems that you are using the IBM i Access ODBC driver through PDO_ODBC. The IBM i Access ODBC driver connects to a QZDASOINIT prestart job running in QUSRSYS subsystem. If you want those jobs to use a different job description, you need to use CHGPJE to change it: CHGPJE SBSD(QUSRSYS) PGM(QSYS/QZDASOINIT) JOBD(MYLIB/MYJOBD). If you're using SSL connections, also change QZDASSINIT jobs. You'll need to end any existing QZDASOINIT/QZDASSINIT jobs and the new pre-start jobs will pick up the new settings. Note that this will affect all ODBC, JDBC, OLEDB, .NET connections for IBM i Access drivers.
You can configure the library list through the DSN as well, by setting the DBQ connection string or DefaultLibraries ODBC.INI setting or setting the "Library List" value under the Server tab from the DSN configuration GUI on Windows.
I work on a personal website. I just put it on the production server. When I am in the development environment I connect to MySQL with root but now I just created a user specific for this website. So I wrote this command line in MySQL:
GRANT USAGE ON portefolio.* TO 'userPortefolio'#'localhost' IDENTIFIED BY PASSWORD 'myPasswordCrypted'
The query is ok, but on my website, when I try to access a page with a query, Symfony gives me that error:
SQLSTATE[42000] [1044] Access denied for user 'userPortefolio'#'localhost' to database 'portefolio'
I tried to restart the server to be sure everything is ok but nothing.
I encrypted the password with the MySQL function
password('my password not encrypt')
and in Symfony I wrote the password in non-encrypted format. Is that ok?
GRANT USAGE ON portefolio.* TO 'userPortefolio'#'localhost' IDENTIFIED BY PASSWORD 'myPasswordCrypted'
Your password should not be encrypted in this statement. MySQL crypts it automatically.
Assuming no quirks in connecting etc were made you should do a
flush privileges;
after running the grant query.
quoting from the manual: The USAGE privilege specifier stands for “no privileges.”
so everything seems to be working as designed.
I have an EC2 instance running a WordPress site. The WordPress db is on a RDS instance. I want to connect to the db over SSL.
From what I've read, the MySQL extension that WordPress uses out of the box doesn't support SSL. So, I've installed a WordPress db script that uses MySQLi, which does support SSL.
The problem I encountered is that Amazon only supplies one key file (more info), and all the examples I can find using MySQLi over SSL include at least 3 files:
$db = mysqli_init();
$db->ssl_set('server-key.pem','server-cert.pem','cacert.pem',NULL,NULL);
I'm able to connect to my db over SSL from the mysql command line app. Can anyone tell me what I need to do to get PHP's MySQLi extension to work, given that I only have the 1 file?
Turns out this was less complicated than I thought. Turning up the error reporting level uncovered an error in my code that I hadn't caught. Using ssl_set this way works:
$db = mysqli_init();
$db->ssl_set(NULL,NULL,'/path/to/mysql-ssl-ca-cert.pem',NULL,NULL);
$db->real_connect($dbhost,$dbuser,$dbpassword,$dbname);
Try this:
$db = mysqli_init();
$db->ssl_set(null, 'https://rds.amazonaws.com/doc/mysql-ssl-ca-cert.pem', null, null, null);