illuminatech / config Goto Github PK

As dots are internally replaced by php with undercores in $_POST

See
https://www.php.net/variables.external
symfony/symfony#9009

As a result we have:

in form:

<input type="text" name="foo.bar" value="10">

in $request->all():

[
    "foo_bar" => "10"
]

in \Illuminatech\Config\PersistentRepository::makeValidator rules:

["foo->bar"]=>
  array(2) {
    [0]=>
    string(9) "sometimes"
    [1]=>
    string(7) "integer"
  }

Thus validation rules are not applied and value not saved.

What steps will reproduce the problem?

Extending Illuminatech/Config/Providers/AbstractPersistentConfigServiceProvider and calling parent::register()

What is the expected result?

No error thrown.

What do you get instead?

The error "Target class [cache.store] does not exist." is thrown from line 75 of AbstractPersistentConfigServiceProvider.

Additional info

Sorry if this is not enough information. Please let me know if I can provide more. I may be missing some step but I am following the README to implement this.

What steps will reproduce the problem?

Call \Illuminatech\Config\PersistentRepository::getItems()->toArray()

What is the expected result?

Returns an array with 'encrypt' attribute.

What do you get instead?

An array without the encrypt attribute.

Additional info

This makes the solution provided here invalid.

The issue I was trying to fix in #2 still continues. The fix I proposed works fine, but doing it in userland requires a bunch of hacks to overload a bunch of package methods. It'd be preferable for the package to just do it itself.

In this particular case it's iterating over a config that was dynamically created by hyn/multi-tenant, but barfs when it finds it to be an array:

I am trying to use this package as having a persistent configuration repository will be very useful for my purposes. I have created a Service Provider that on boot() will extend the configuration service class like so:

       $this->app->extend('config', function ($originConfig) {
            $storage = new StorageEloquent(ConfigurationItem::class);
            return (new PersistentRepository($originConfig, $storage))
                ->setCache($this->app->make('cache.store'))
                ->setCacheKey($this->configItemCacheKey)
                ->setCacheTtl($this->configItemCacheTtl);
        });

This works as expected. If I also call setItems() in the same statement, they are retrieved from the database using the Eloquent model.

However, I also have many other "services" with their own Service Provider. I was hoping to be able to instruct the PersistentRepository in the boot() method of each Service Provider what the configuration items (->setItems()) are for each service. Unfortunately, it seems that calling ->setItems() will completely overwrite previous calls. It would be extremely useful to call this multiple times to "build up" the list of persistent configuration items managed by the repository.

What steps will reproduce the problem?

Configure persistent repository with the item, which id does not match its key, set new value to this item and invoke synchronize():

$persistentRepository = new PersistentRepository(/* ... */);
$persistentRepository->setItems([
     'custom.id' => [
        'id' => 'custom_id',
    ],
]);

$persistentRepository->set('custom.id', 'new value')

$persistentRepository->synchronize();

What is the expected result?

New value is saved inside the persistent storage.

What do you get instead?

New value is ignored.

Additional info

I'm sorry but I love the idea, but your documentation is very poorly written and lacking support on how to get properly started, migration, best practice during boot-time.

What steps will reproduce the problem?

Define a non-encrypted setting, and persist it.
Then change the properties to set 'encrypt' => true.
Now attempt to read persisted values (ie: load any page in the app).

What is the expected result?

Expected no app errors.

What do you get instead?

The following error occurs, presumably because it's assuming the existing persisted setting is already encrypted.

[2019-07-10 15:31:04] local.ERROR: The payload is invalid. 
{"userId":123,
"exception":"[object] (Illuminate\\Contracts\\Encryption\\DecryptException(code: 0): The payload is invalid. 
at vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php:195)"
} []

Additional info

Workaround

The only (and unfriendly) workaround appears to be to manually delete the setting from persisted storage, then run the app and collect the setting value via the app and have the app save it "fresh".

What steps will reproduce the problem?

If I set two configuration items like the following:

setItems([            'services.example.item1' => [
                'label' => 'Item 1',
                'rules' => ['required', 'array'],
                'cast' => 'array'
            ],
            'services.example.item2' => [
                'label' => 'Item 2',
                'rules' => ['required', 'array'],
                'cast' => 'array'
            ]
])

And then I try to retrieve them like so:

Config::get('services.example')

Nothing is returned (null).

What is the expected result?

I should get an array of configuration items, item1 and item2.

What do you get instead?

I get a null response.

Additional info

The issue seems to be related to the call to isPersistentKey when calling get

Additionally, if I call Config::restore() beforehand, I am able to get the expected result.

During the Laravel 7.0 development the way dot keys are handled during validation has been changed.
See:

laravel/framework@4a4a7e1#diff-38fd116b7c7b8ac1bdd8362250d04d57

Thus method PersistentRepository::validate() is unable to handle item ID with dots anymore.

Relates to laravel/framework#33932

This should be fixed along with upgrade to Laravel 8.0.

What steps will reproduce the problem?

When running composer install --no-dev --optimize-autoloader -vvv, the command php -d allow_url_fopen='1' -d disable_functions='' -d memory_limit='1536M' artisan package:discover --ansi is also run.

Because this loads the service providers, a database connection will be attempted for the configuration items. When, for example, building your code base on a CI/CD server, this will hang until a timeout because it cannot connect to the database.

What is the expected result?

Avoid a database connection during artisan/build commands.

What do you get instead?

Timeout on database connections.

Additional info

Fix typo in Illuminatech\Config\StorageContact interface name:

- Illuminatech\Config\StorageContact;
+ Illuminatech\Config\StorageContract;