API output changed with 1.6.0 (PHP8), which breaks automation tools like Terraform
Describe the bug After upgrading to version 1.6.0 with PHP 8 , we noticed that the API output changed, which breaks automation Tools like Terraform and the phpipam Terraform provider.
The issue was first addressed with the provider itself here https://github.com/lord-kyron/terraform-provider-phpipam/issues/84 but i have the feeling it makes sense to also raise it here, as i am still unsure if the change in behaviour is intended.
In its core, the issue seems to be that phpipam now with PHP8 seems to return integers and floats using native PHP types instead of strings.
See here https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo.mysql
The issue for now appears with the sections API but might be seen elsewhere.
Below is a section output of the error, on what the returned response for Section now with 1.6.0 looks like:
v1.6.0
curl -X GET https://my-phpipam.net/api/apiclient/sections/ --header "token: MY_TOKEN" -i
{
"id": 1,
"name": "Customers",
"description": "Section for customers",
"masterSection": 0,
"permissions": "{\"3\":\"1\",\"2\":\"2\"}",
"strictMode": "1",
"subnetOrdering": null,
"order": 3,
"editDate": "2022-12-22 10:48:16",
"showSubnet": 1,
"showVLAN": 0,
"showVRF": 0,
"showSupernetOnly": 0,
"DNS": null
},
Running the following API call against the 1.5.2 instance reveals that the response looks different there:
v1.5.2
curl -X GET https://my-phpipam.net/api/apiclient/sections/ --header "token: MY_TOKEN" -i
...
{
"id": "1",
"name": "Customers",
"description": "Section for customers",
"masterSection": "0",
"permissions": "{\"3\":\"1\",\"2\":\"2\"}",
"strictMode": "1",
"subnetOrdering": null,
"order": "3",
"editDate": "2022-12-22 10:48:16",
"showSubnet": "1",
"showVLAN": "0",
"showVRF": "0",
"showSupernetOnly": "0",
"DNS": null
},
Other users have experimeted with using PDO::ATTR_STRINGIFY_FETCHES to restore the old behaviour which seems to work, however its unclear if that breaks something else.
phpIPAM version 1.6.0
Would be nice if somebody did fix the issue.
Would be nice if somebody did fix the issue.
Would be nice if the PHP bods would stop creating them.
https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo.mysql
MySQL Driver
Integers and floats in result sets will now be returned using native PHP types instead of strings when using emulated prepared statements. This matches the behavior of native prepared statements. The previous behaviour can be restored by enabling the PDO::ATTR_STRINGIFY_FETCHES option.
Hi @GaryAllan Can be this workaround to be applied to mitigate issue?
Although not a long-term solution, updating PHPIPAMs class.PDO.php seems to work as a temporary workaround.
diff --git a/functions/classes/class.PDO.php b/functions/classes/class.PDO.php
index ba2d379e..33f28418 100644
--- a/functions/classes/class.PDO.php
+++ b/functions/classes/class.PDO.php
@@ -189,6 +189,7 @@ abstract class DB {
}
$this->setErrMode(\PDO::ERRMODE_EXCEPTION);
+ $this->pdo->setAttribute(\PDO::ATTR_STRINGIFY_FETCHES, true);
} catch (\PDOException $e) {
throw new Exception ("Could not connect to database! ".$e->getMessage());
Originally posted by @dejongm in https://github.com/lord-kyron/terraform-provider-phpipam/issues/84#issuecomment-1959896507
Hi @GaryAllan Can you please look on this issue?
We need a decision from you whether support for the previous API format will be added or whether you decide that the old format will no longer be supported
Hello,
I can add a config.php option to stringify API responses, but the default will be to follow the PHP behavior.
It's the same patch you're already applied yourself.
See config.php $api_stringify_results option and header
curl -X GET --header "token: <token>" --header "api-stringify-results: 1" https://phpipam/api/myapp/subnets/
Hi @GaryAllan , thank you for update. Could you please create a new minor release with this feature?
@GaryAllan can you release new version with api-stringify?
@GaryAllan can you please look at @pavel-z1 latest comment? We need this. Thanks!