Bad signature error listing buckets

[rushabhpasad]

@dkocher @ylangisc
I am using Cyberduck to connect to on premise object storage system. With the release of v8.4.3, I am unable to list the buckets (root directory) on all the file systems, that are working with v8.4.2. After going through the change log, the issue seems to be with PR #13664. This PR makes bucket name to be a mandatory field and disallows the listing of all buckets. Can this issue be addressed?

PS: Due to this change, creation of bucket is impossible using the Cyberduck client.

[dkocher]

Can you provide information about the S3 server implementation and a HTTP transcript ¹.

Footnotes

1. https://docs.cyberduck.io/cyberduck/support/#logging-output ↩

[rushabhpasad]

I do not have the information for the s3 server implementation.

Attached is the log file containing the exception and relevant details. Sensitive information has been redacted.

cyberduck.log

[dkocher]

The log confirms that the GET / to list all buckets is returned with a 401 error indicating a problem with the signature for the request sent in the Authorization header. For listing buckets the default region us-east-1 is used as no region can be derived from a bucket. @rushabhpasad Can you compare the Authorization header sent between the 8.4.2 and the current release?

If the region in the AWS4 request signature is the problem, this could probably be resolved by creating a custom connection profile with a preconfigured default region like

    <key>Region</key>
    <string>us-phoenix-1</string>

See ¹ for examples.

Footnotes

1. https://github.com/iterate-ch/profiles ↩

[dkocher]

I do not have the information for the s3 server implementation.

The response shows Server: dlb/1.0.2. Would be interested to know what S3 implementation that refers to.

[rushabhpasad]

I don't believe there is any region associated with our implementation. Attaching the logs from v8.4.2 which doesn't throw the exception.
cyberduck-8.4.2.log

[dkocher]

We obfuscate the Authorization in the transcript, thus I cannot tell the difference. @rushabhpasad You will have to inspect using a proxy such as ¹.

Footnotes

1. https://proxyman.io/ ↩

[rushabhpasad]

After looking at the Authorization in proxy - the pattern is same between both the versions-

Authorization: AWS <user-id>:<token>

[rushabhpasad]

Also, in the new version, when path is provided while opening the connection /<bucket-name>, it opens the bucket fine, but fails to open /.

[rushabhpasad]

@dkocher Any luck with this one?

[dkocher]

We are currently reviewing request signature calculation in #14882.