AWS S3 Not Working on New DigitalOcean Server ('During inheritance of Countable' Error)

Hi there…

I think this is one for @patrick

I’m just moving my app to DigitalOcean, and my AWS S3 File uploader has stopped working.

I’m using PHP 8.1 on the server, and Wappler 3.9.7.

I’m wondering if there is some kind of PHP extension I should have installed on the Droplet.

In the Network tab of the browser, I get the message:

During inheritance of Countable: Uncaught ErrorException: Return type of Aws\HandlerList::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/html/dmxConnectLib/aws/Aws/HandlerList.php:308\nStack trace:\n#0 /var/www/html/dmxConnectLib/aws/Aws/HandlerList.php(32): exception_error_handler()\n#1 /var/www/html/dmxConnectLib/aws/aws-autoloader.php(1463): require(’…’)\n#2 /var/www/html/dmxConnectLib/aws/Aws/AwsClient.php(197): {closure}()\n#3 /var/www/html/dmxConnectLib/aws/Aws/S3/S3Client.php(328): Aws\AwsClient->__construct()\n#4 /var/www/html/dmxConnectLib/modules/s3.php(30): Aws\S3\S3Client->__construct()\n#5 /var/www/html/dmxConnectLib/lib/App.php(195): modules\s3->provider()\n#6 /var/www/html/dmxConnectLib/lib/App.php(127): lib\App->execSteps()\n#7 /var/www/html/dmxConnectLib/lib/App.php(153): lib\App->exec()\n#8 /var/www/html/dmxConnectLib/lib/App.php(159): lib\App->execSteps()\n#9 /var/www/html/dmxConnectLib/lib/App.php(127): lib\App->execSteps()\n#10 /var/www/html/dmxConnectLib/lib/App.php(116): lib\App->exec()\n#11 /var/www/html/dmxConnectLib/lib/App.php(94): lib\App->exec()\n#12 /var/www/html/dmxConnect/api/aws_s3/aws_s3_signup.php(8): lib\App->define()\n#13 {main}"

Here is the S3 part of the server action which works fine on my existing AWS EC2 server:

aws

I’m guessing this has something to do with it…

https://php.watch/versions/8.1/ReturnTypeWillChange

@patrick, I’m wondering if you have updated the dmx files for S3 since 3.9.7 to take into account this #[ReturnTypeWillChange] factor, and I can just grab the upgraded file? :thinking:

I think the problem is in the AWS SDK, download the latest version from Release Version 3.254.1 · aws/aws-sdk-php (github.com)

Thanks @patrick! I’ve done that on the DigitalOcean Droplet and I still have the problem.

Can you suggest something else please?

Thanks!

Antony.

============================
Log from SDK installation:

Info from https://repo.packagist.org: #StandWithUkraine
Cannot use aws/aws-sdk-php's latest version 3.254.1 as it requires ext-simplexml * which is missing from your platform.
Using version ^3.33 for aws/aws-sdk-php
./composer.json has been created
Running composer update aws/aws-sdk-php
Loading composer repositories with package information
Updating dependencies
Lock file operations: 11 installs, 0 updates, 0 removals
  - Locking aws/aws-sdk-php (3.33.4)
  - Locking guzzlehttp/guzzle (6.5.8)
  - Locking guzzlehttp/promises (1.5.2)
  - Locking guzzlehttp/psr7 (1.9.0)
  - Locking mtdowling/jmespath.php (2.6.1)
  - Locking psr/http-message (1.0.1)
  - Locking ralouphie/getallheaders (3.0.3)
  - Locking symfony/polyfill-intl-idn (v1.27.0)
  - Locking symfony/polyfill-intl-normalizer (v1.27.0)
  - Locking symfony/polyfill-mbstring (v1.27.0)
  - Locking symfony/polyfill-php72 (v1.27.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 11 installs, 0 updates, 0 removals
  - Downloading symfony/polyfill-mbstring (v1.27.0)
  - Downloading mtdowling/jmespath.php (2.6.1)
  - Downloading ralouphie/getallheaders (3.0.3)
  - Downloading psr/http-message (1.0.1)
  - Downloading guzzlehttp/psr7 (1.9.0)
  - Downloading guzzlehttp/promises (1.5.2)
  - Downloading symfony/polyfill-php72 (v1.27.0)
  - Downloading symfony/polyfill-intl-normalizer (v1.27.0)
  - Downloading symfony/polyfill-intl-idn (v1.27.0)
  - Downloading guzzlehttp/guzzle (6.5.8)
  - Downloading aws/aws-sdk-php (3.33.4)
  - Installing symfony/polyfill-mbstring (v1.27.0): Extracting archive
  - Installing mtdowling/jmespath.php (2.6.1): Extracting archive
  - Installing ralouphie/getallheaders (3.0.3): Extracting archive
  - Installing psr/http-message (1.0.1): Extracting archive
  - Installing guzzlehttp/psr7 (1.9.0): Extracting archive
  - Installing guzzlehttp/promises (1.5.2): Extracting archive
  - Installing symfony/polyfill-php72 (v1.27.0): Extracting archive
  - Installing symfony/polyfill-intl-normalizer (v1.27.0): Extracting archive
  - Installing symfony/polyfill-intl-idn (v1.27.0): Extracting archive
  - Installing guzzlehttp/guzzle (6.5.8): Extracting archive
  - Installing aws/aws-sdk-php (3.33.4): Extracting archive
4 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
7 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found

Where was it installed? You need to replace the one in the dmxConnectLib/aws folder. You can just copy the new version over it.

I see the version that composer is installing on your system is an old version, that version is from 2017. It seems that simplexml extension is not installed on your server, perhaps that is the cause of the error.

Hi @patrick

Okay, so I’m a bit confused…

I thought I needed to install the SDK on my Droplet using Composer.

Was that necessary?

I can install simplexml and reinstall the SDK…

In this message, are you saying I should take the zip file for the SDK and copy the files to dmxConnectLib/aws? (But you mention “The one”… the one what?)

If you could give me a slightly more detailed set of steps to follow, that would be amazing…

Thank you! :pray:
Antony.

Easiest is to just download the zip file from the github releases page. Unzip it in the dmxConnectLib/aws folder.

Using Composer will install it in the vendor folder, server connect doesn’t look for the includes there and will not find it, so you need to move it to the dmxConnectLib/aws folder afterwards. I don’t know if Composer does more then downloading the latest version, it seems to do at least do a requirements check which pointed us to the missing simplexml extension and downloads a version that should work with the missing extension.

Hi @Patrick

Thanks for the details!

I’ve unzipped the files into dmxConnectLib/aws… and installed the latest sdk on the server.

It has fixed the first problem, and created another, which now happens both on my existing installation and on the new Droplet. Details are below…

What else can I try?

Best wishes,
Antony.

==========

I took the zip file from here:

When it fails, here is the Network activity:

So the first server action listed contains the S3 upload component. This was failing with the “countable” error before, and now it is completing successfully.

Red failed item… 41_…marketing.jpg is the filename uploaded to the S3 server. The result of this call failing is that the aws_s3_signup.php flow stops working.

… the 403 header contains:

Request URL: https://s3.eu-west-2.amazonaws.com/files.workshop-angel.com/41_89707fda4c700625_conscious_marketing.jpg?x-amz-acl=&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA53SUIXJIF5XAQV3R%2F20221222%2Feu-west-2%2Fs3%2Faws4_request&X-Amz-Date=20221222T144819Z&X-Amz-SignedHeaders=host%3Bx-amz-acl%3Bcontent-md5&X-Amz-Expires=300&X-Amz-Signature=7e00b5ef839efb5c71f056fe65f39091ae521b71ab65726846401c0206475e75
Request Method: PUT
Status Code: 403 Forbidden
Remote Address: 52.95.144.45:443
Referrer Policy: strict-origin-when-cross-origin

When this works correctly on my existing server with the old dmxConnectLib/aws folder, the 200 header looks like this:

Request URL: https://s3.eu-west-2.amazonaws.com/files.workshop-angel.com/30_2c6903849222df99_conscious_marketing.jpg?x-amz-acl=&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA53SUIXJIF5XAQV3R%2F20221222%2Feu-west-2%2Fs3%2Faws4_request&X-Amz-Date=20221222T144744Z&X-Amz-SignedHeaders=host%3Bx-amz-acl&X-Amz-Expires=300&X-Amz-Signature=2784e3ca70dd03b0f25a84f0d66e25e22a37221c93ebd7d3968ed1559404b7a9
Request Method: PUT
Status Code: 200 OK
Remote Address: 52.95.144.45:443
Referrer Policy: strict-origin-when-cross-origin

FYI, the installation of the SDK on the Droplet went like this…

Info from https://repo.packagist.org: #StandWithUkraine
Using version ^3.255 for aws/aws-sdk-php
./composer.json has been updated
Running composer update aws/aws-sdk-php
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 1 update, 0 removals
  - Locking aws/aws-crt-php (v1.0.2)
  - Upgrading aws/aws-sdk-php (3.33.4 => 3.255.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 1 update, 0 removals
  - Downloading aws/aws-crt-php (v1.0.2)
  - Downloading aws/aws-sdk-php (3.255.0)
  - Installing aws/aws-crt-php (v1.0.2): Extracting archive
  - Upgrading aws/aws-sdk-php (3.33.4 => 3.255.0): Extracting archive
Generating autoload files
7 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found

Problem with the AWS SDK is that it changes so oft, that’s why we aren’t updating it that often. The difference in the url seems to be content-md5 which it should not add since we don’t send a md5 hash of the content with the request.

Since you still use an old Wappler it is possible that you don’t have all the latest files, so here is the latest s3 module, unzip in dmxConnectLib/modules. It is also possible that the latest version on Github has some breaking changes.

s3.zip (1.6 KB)

The last version of the SDK we had bundled was 3.148.0 and I have a test here in development with 3.219.3. Since there are daily updates in the SDK it is difficult to keep track of them all and we already had several times with the NodeJS version that they broke something with their update.

1 Like