After 📌 Clean up unserialize() in the config system Active was Fixed, @alexpott and I discussed the issue further and agreed on this followup.
Drupal\Core\Config\Config::save() calls validateValue() (either directly or indirectly, via castValue()). That ensures that proper use of the config system protects against serializing anything other than nested arrays of scalar types. However, the validation is skipped if the optional $has_trusted_data parameter is set to TRUE:
public function save($has_trusted_data = FALSE) {
// ...
if (!$has_trusted_data) {
if ($this->typedConfigManager->hasConfigSchema($this->name)) {
// Ensure that the schema wrapper has the latest data.
$this->schemaWrapper = NULL;
$this->data = $this->castValue(NULL, $this->data);
}
else {
foreach ($this->data as $key => $value) {
$this->validateValue($key, $value);
}
}
}
Install Drupal with the Standard profile. Using drush php, execute the following:
$cf = Drupal::configFactory();
$ce->set('foo', (object) ['bar' => 17]);
$ce->save(TRUE);
There is a warning, but the config entity is saved and $ce->get('foo') is a stdClass object:
MariaDB [db]> SELECT * FROM config WHERE name = 'dblog.settings'\G
*************************** 1. row ***************************
collection:
name: dblog.settings
data: a:3:{s:5:"_core";a:1:{s:19:"default_config_hash";s:43:"e883aGsrt1wFrsydlYU584PZONCSfRy0DtkZ9KzHb58";}s:9:"row_limit";i:1000;s:3:"foo";O:8:"stdClass":1:{s:3:"bar";i:17;}}
1 row in set (0.001 sec)
Update the code so that $has_trusted_data bypasses config validation but not basic validation: the config object should represent a nested array of scalar values.
None
None
None
None
N/A
Active
11.0 🔥
configuration system
Using the code in the MR, the testing steps with drush php lead to an exception:
> $ce->save(TRUE)
Drupal\Core\Config\UnsupportedDataTypeConfigException Invalid data type for config element dblog.settings:foo.
Let's added some test coverage of this behaviour. We could add this to \Drupal\KernelTests\Core\Config\ConfigCRUDTest::testDataTypes