Orphaned primary_key_table_fields causing errors after upgrade from 9.21 to 9.22

[taubes]

Hi,

I ran into some issues after upgrading a copy of my main Dadabik application from 9.21 to 9.22. Basically after the update to 9.2.2 I get unexpected "primary_key_table_field = xxx" errors for all tables and views that are still linked somewhere as a "primary_key_table_field" even for not-enabled and uninstalled tables and views. This is 9.22 specific if I switch back 9.21 all is fine again.

The solution seems very elaborate:
- re-enable all not-enabled databases then turn off READ in the permissions for all groups to prevent them showing up in the menu
- find orphaned primary_key_table_field data in tables/views that have been uninstalled.

The main problem is that the error message only references the "primary_key_table_field = xxx" but not the table causing this error. Very elaborate when dealing with deleted tables/views because the only way to find the culprits is search for the tables in the dadabik_forms table or go through all table/views looking for the orphaned primary_key_table_field.

Question:
Is 9.22 more strict regarding orphaned primary_key_table_fields. Is this on purpose? Or am I overlooking a config setting. It was convenient to not-enable databases that were only needed for drop downs instead of setting the permissions for multiple groups. This also reduced the number of tables shown in the permission (I have almost 100 tables and many I only need for drop-downs).

---
You are using DaDaBIK version 9.2.1-Monterosso enterprise ...
You are using DaDaBIK version 9.2.2-Monterosso enterprise ...

PHP Version: 5.6.37
mysql version: 5.7.23
Web server: Apache/2.4.34 (Unix) PHP/5.6.37
Client: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15

 

[eugenio]

Hello,
could you post an example of the exact error message you are getting?

Best,

 

[taubes]

Hi,

All I get is "unexpected primary_key_table_field: admin_categories" no other information.

Found the culprit: the new $form_config_security_check = 1; is causing this (did not see this because I copied the config.php from 9.21). When this is set to 1 and a table has a primary_key_table_field linked to a disabled or uninstalled table you get the error message.
Every time.

Best

Stefan

 

[eugenio]

Hi Stefan,
$form_config_security_check was already available in 9.2.1 as well, so probably part of your config.php was copied form an older version.

The best way to upgrade is always to keep note of the parameters you changed, use the new config.php and replace the parameters.
This might change soon because I would like to introduce a config_custom.php file, that you can keep during upgrades, containing all and only the parameters you have changed.

Best,

 

[dh]

taubes Wrote:
-------------------------------------------------------
> Hi,
>
> All I get is "unexpected primary_key_table_field:
> admin_categories" no other information.
>
> Found the culprit: the new $form_config_security_c
> heck = 1; is causing this (did not see this becaus
> e I copied the config.php from 9.21). When this is
> set to 1 and a table has a primary_key_table_field
> linked to a disabled or uninstalled table you get
> the error message.
> Every time.
>
> Best
>
> Stefan

I can confirm that this is also the situation upgrading from 9.0 to 9.3 which I just did. I experienced the same issue of a view installed in DaDaBIK but *not* enabled, triggering the error message.

Eugenio, I see in another thread that you recommend against setting this form_config_security_check parameter to 0, but it is the only way to avoid the error other than the roundabout method taubes describes above, which I was also about to try. Unless there's a huge security risk involved, I am going to set to 0 in all my installed instances after upgrade.

 

[eugenio]

Hello David and Stefan,
I think I misunderstood Stefan's post when I read it; I thought the problem was due to the fact that $form_config_security_check =1 WAS NOT in config.php but it was actually there and the post was clear.

If you use a table for a lookup field (as primary_key_table_field) I confirm the table must be installed and enabled in DaDaBIK, this is a security measure. You don't necessary need to set the permissions, though: users can still read its records if the table is used as source of a select_single/select_multiple field or as items table in a master/details view.

I hope this clarify the issue.

Best,

 

[dh]

Thank you... appreciate the confirmation. What is still not clear is how bad the security issue is if you set =0.

 

[eugenio]

It's difficult to give a precise measure about how bad it is.

Basically some parameter values in form configurator become part of SQL queries so they might be a "door" for an SQL injection attack if someone managed to intentionally store malicious content in those parameters or if for some other reason (a bug, for example) some content different than the one supposed to be there is stored.

If you check, for example, that primary_key_table_field actually contains a table that you have installed and enabled in DaDaBIK, you add a layer of security, because in order to install a table, its name needs to follow some rules and if you have an installed table having a "weird" name DaDaBIK alerts you about that.

The security of the application, however, depends on many many factors.

Is there any particular reason why you prefer not to enable those tables?

Best,