CIVI_DB_ARGS, etc is empty but CIVI_DB_DSN has string

[herbdool]

This is happening in version v0.3.10 and from the most recent build (I downloaded the repo and ran ./build.sh and found cv.phar created in ./bin - which is undocumented by the way) :

  ["CIVI_DB_ARGS"]=>
  string(0) ""
  ["CIVI_DB_DSN"]=>
  string(89) "mysql://civicrm:civicrm@localhost:3306/civicrm?new_link=true"
  ["CIVI_DB_HOST"]=>
  string(0) ""
  ["CIVI_DB_NAME"]=>
  string(0) ""
  ["CIVI_DB_PASS"]=>
  string(0) ""
  ["CIVI_DB_PORT"]=>
  string(0) ""
  ["CIVI_DB_USER"]=>

This was working not too long ago.

[herbdool]

@totten I only got around to investigating now. In

cv/lib/src/SiteConfigReader.php

Line 169 in c161ddc

$url = parse_url($dsn);

it is using parse_url(). But it can't handle some characters in the password that are otherwise fine when set in civicrm.settings.php. In our case, we've just changed the passwords to exclude characters like: # (they already exclude @, : and some others.

[totten]

@herbdool Oh, wow. I see. So there are slight differences between parse_url() and DB::parseDSN()?

I guess the objective should be RFC compliance for both. RFC 1738: section 2.2 calls out # as generally "unsafe", so translating # => %23 would be canonical. But parsers could differ in how "forgiving" they are about unsafe values. And parsers can also be buggy.

I wanted to understand their behavior better. Quick comparison script:

// Run with "cv scr this-file.php"
$exs = [
  'mysql://user:pass%[email protected]/foo',
  'mysql://user:pass#[email protected]/foo',
];

foreach ($exs as $ex) {
  print_r([
    'raw' => $ex,
    'parse_url' => parse_url($ex),
    'DB::parseDSN' => DB::parseDSN($ex),
  ]);
}

Which gives results:

Scenario	parse_url()	DB::parseDSN()
user:pass%23word (RFC conformant)	OK, but you need an extra call to urldecode()	OK
user:pass#word (non-conformant)	Fails completely	OK

IMHO, it's probably fair for parse_url() and SiteConfigReader to reject literal #, but it's also buggy because it neglects to decode %23.

Is it safe to fix the bug?... I'm not certain. Probably?

[herbdool]

Are you talking about a bug in cv or in core? Or both? From what I understand DB:parseDSN should be stricter and reject more characters, and cv needs to include a urldecode()?

In Civi\Setup\DbUtil::parseDsn() I see this: $parsed = array_map('urldecode', parse_url($dsn)); but you'd probably want the whole method to use in cv.