Do not use URL syntax for database settings

Which specific characters are you trying to encode in your password? Using "%40" for the @ symbol resolved the issue for me; if you have the problem with particular symbols, perhaps I could test it here as well.

My apologies; spoke too soon. After experimenting with some more, it does indeed still fail. I will check tomorrow to see if this has been included in 4.6.2; if not, I can attach a patch to this report. Not sure yet if that's how things are done here.

I can confirm that I was having the same problem. I had an @ in a mysql password, and the "%40" encoding was not working, so I then tested a "%40" in the username. It definately was not being converted to a "@" symbol. I added these lines from above:

$url['host'] = urldecode($url['host']);
$url['user'] = urldecode($url['user']);
$url['pass'] = urldecode($url['pass']);
$url['path'] = urldecode($url['path']);

and everything worked just fine.

If we would go this route then people with a percent sign in their db_url would get problems and what's worse it would break their update path, they would need to urlencode their passwords before an update. I am a bit reluctant to make this step.

hey guys...first-timer here..
I was hoping to get a smooth install so I could see how drupal works, but Im having problems with my database/user-names.
I use the undersquare "_" and I can't seem to find the hex codes to encode. I only found the htmlcode for it.. "_" , but that doens't work...

Does someone know ??

Thanks in advanced!

I think we can indeed fix this by adding a urldecode and telling everybody to add hexcode for % in the docs on update.php.

I also think this is very important issue and should be fixed before 4.7

Bumping.

If we really are not going to fix this for 4.7, then we should change the docs.

i can verify that this is an issue with drupal 4.7b3 + pgsql 812 on OSX 10.4.4.

with my pg_hba.conf entry as:

hostssl drupaldb myuser 127.0.0.1 255.255.255.255 md5

using *any* special character (literal, "\"-escaped, or urlencoded) in $db_url's 'password' simply causes the connect to fail.

removing any/all suchh chars form password, everything's fine with plaintext/md5 pwds over encrypted SSL to DB.

richard

eek ... didn't mean to 'yell' ...

Patch against cvs for db_connect for MySQL, MySQLi, and PostgreSQL.

The best solution would be to use some other variable than $db_url
If $db_url is set, use old method, if $new_config is set - use new method
Very simple to implement and backward compatibile.
Would allow us to drop this ugly url-like syntax and add new features

IMO this is commit ready. The number of people who have such special characters in their username/password should be tiny and it's simple enough to fix.

Commit if you want, but it'll break the update path for those who have a percent sign in their password. Given the even smaller number of those, I think this one is good to go.

Committed.

Well, indeed, it busted my Drupal install when I upgraded to 4.7. I had a plus sign in my MySQL password.

Guess what? That's a perfectly valid URL, too. Plus signs are only URL delimiters when they occur after the question mark ? sign in the path to the right of the hostname.

My site worked for 2 years, and then blew up when I installed 4.7 because this patch tossed the plus sign with urldecode().

My host uses autogenerated MySQL passwords and they can include plus signs. How many people do you suppose are going to get screwed by this? It's especially hard to figure out because the admin knows the database parameters are right because they were working and were not changed with the install. Because of that, the site admin is unlikely to read the comments in the settings.php file and notice that the plus sign needs to be hex encoded. Instead, that admin is going to contact their host and ask WTF is wrong with the database connection.

In fact, the standard for URLs specifically says + signs are valid and are not to be encoded. See here: http://www.ietf.org/rfc/rfc1738.txt

This fix breaks that standard.

PHP's parse_url() handles it correctly and returns the + sign.

You should encode "+" as settings.php says. UPGRADE.txt should be updated to reflect this.

If the + is an issue, we should use rawurlencode() and rawurldecode(). The non-raw versions are meant for query string arguments really.

i agree that the url syntax confuses people for no good reason (that I can think of). separate fields makes better since to me.

I'm OK with seperate fields if that is going to fix a bunch of problems. Use $db_ not $db.

Changing that setting will complicate the upgrade process though. People will be forced to edit their settings.php before they can even attempt to upgrade... Maybe this should be put on hold for 4.8?

i also am inclined to wait on this. workarounds are available so i set to normal priority.

moving

seems like noone cares anymore. reopen if i am wrong.

Marking won't fix. We have an installer now that takes care of this for you, so there should very rarely need to be a reason to go in and putz with settings.php.