Upgrading from version 2.0

[alexander-zierhut]

Description:
I am having this issue while trying to validate upgrading this lib from v2.0 for an external project. A non AWS provider is used. From debugging the Request object created, I found the following headers:

Array
(
    [0] => x-amz-acl: public-read
    [1] => Host: storage:9090
    [2] => Date: Sun, 04 Feb 2024 22:43:34 +0000
    [3] => Content-MD5: aLRqb9GImLBE62a9FL7opQ==
    [4] => Content-Type: image/jpeg
    [5] => Content-Length: 9111
    [6] => Authorization: AWS access_key:XSdth2mvbuJqcif1JX9bF1q5byc=
)

Fatal error:
Uncaught Akeeba\S3\Exception\CannotPutFile: Akeeba\S3\Connector::putObject(): [500] AccessDenied:AWS authentication requires a valid Date or x-amz-date header

Debug info:
SimpleXMLElement Object

(
    [Code] => AccessDenied
    [Message] => AWS authentication requires a valid Date or x-amz-date header
    [RequestId] => tx54473b1f03e048108d92a-0065c00ea0
)

Stack trace:
in /var/www/html/vendor/akeeba/s3/src/Connector.php:149
Akeeba\S3\Connector->putObject()

[nikosdion]

Are you using Amazon S3, or something different?

Which one are you using, v2 or v4 signatures?

Have you tried using the development branch?

[alexander-zierhut]

Are you using Amazon S3, or something different?

• Something different. Scaleway.

Which one are you using, v2 or v4 signatures?

• v2

Have you tried using the development branch?

• No, but I can if you'd like me to.

[nikosdion]

I believe that the third party service may be in the wrong here. Amazon AWS allows you to use either the standard HTTP header Date, or the custom HTTP header X-Amz-Date. For v2 signatures we use the former. Moreover, AWS documents that they expect a ISO 8601 formatted date, but they in fact expect a date formatted with RFC1123. I believe that whatever S3 compatibility layer they are using cannot parse a correctly formatted RFC1123 date, namely the caveat explained in section 5.2.14, third paragraph:

There is a strong trend towards the use of numeric timezone
indicators, and implementations SHOULD use numeric timezones
instead of timezone names. However, all implementations MUST
accept either notation. If timezone names are used, they MUST
be exactly as defined in RFC-822.

They apparently only expect numeric timezone indicators which means they are not compliant.

[alexander-zierhut]

I will look into it and talk to them to find out if that's the case. Did you change the format between versions? Which was is it using now?

[nikosdion]

I mean, 2.0 was released three years ago. Yeah, sure, a lot has changed! See here: 2.0.0...2.3.1 What you are looking for is here d1797b6 This was necessary for v4 signatures to work.

[nikosdion]

You can now select whether to use the X-Amz-Date or Date HTTP header for the requests. This should address your issue.