Figure out SignatureDoesNotMatch issue

[bcspragu]

Currently, the API can issue temporary credentials that have a policy allowed to access a random /temp/... scratchpad in the bucket, but when the Logseq client generates presigned upload URLs, they're invalid. Snippet:

 
Can not upload temp file, code=403: <?xml version="1.0" encoding="UTF-8"?>
<Error>
	<Code>
		SignatureDoesNotMatch
	</Code>
<Message>
	The request signature we calculated does not match the signature you provided. Check your key and signing method.
</Message>

These types of things are always annoying to debug because a single bit in the wrong place messes up the signatures. I've compared the responses from the self-hosted server versus the real server, and they look fine, and I've gone through the s3_presign code used in rsapi, but haven't seen anything obvious yet.

[bcspragu]

An annoying update: I had made a few tweaks and this briefly worked, e.g.:

^^ shows an example of the Logseq client uploading a few encrypted blobs to the S3 bucket successfully, using the STS credentials to generate presigned URLs and then upload things. I haven't been able to replicate this, despite not (as far as I remember) changing anything. But it indicates that it isn't broken in some major way, just some finicky minor way.

[bcspragu]

Okay, I've traced this to the s3-presign crate used by Logseq's rsapi code, and until that's fixed upstream, I can continue development using my fork, which swaps out the s3-presign crate for the rust-s3 crate.

Here's the upstream issue on logseq/rsapi, I'm closing this one out.