fix: images not loading due to signature mismatch

[NuclearRedeye]

See here, we are configuring the values to key and secret but when using localstack they should both be test. This updates the config to set them to the desired values.

[NateWr]

Progress... I'm now getting a 404 response to the image request. I looked in the output from docker-compose up and found the following lines:

editor-article-store    | 1616581933756 : Processing GET for /54296/assets/elife-54296-fig1.jpeg
editor-article-store    | Asset URL not found for 54296/625f0bc9-80b7-4f88-bb46-0f99ef046ee7/elife-54296-fig1.jpeg

I tried a fresh clone of the repository and checked out fix/image-signing-mismatch, then ran docker-compose up. I got the same result.

I noticed this in the logs:

editor-article-store    | Server listening on port 8080
editor-article-store    | SQS - Error interacting with queue -  SQSError: SQS receive message failed: Inaccessible host: `editor-localstack'. This service may not be available in the `us-east-1' region.
editor-article-store    |     at toSQSError (/node_modules/sqs-consumer/dist/consumer.js:41:22)
editor-article-store    |     at Consumer.receiveMessage (/node_modules/sqs-consumer/dist/consumer.js:137:19)
editor-article-store    |     at processTicksAndRejections (internal/process/task_queues.js:93:5) {
editor-article-store    |   code: 'UnknownEndpoint',
editor-article-store    |   statusCode: undefined,
editor-article-store    |   region: 'us-east-1',
editor-article-store    |   retryable: true,
editor-article-store    |   hostname: 'editor-localstack',
editor-article-store    |   time: 2021-03-24T10:38:00.772Z
editor-article-store    | }

But then later I saw this, so I'm guessing this was just the "waiting for everything to boot" part:

editor-article-store    | SQS - S3 upload event received - { Key: elife-54296-vor-r1.zip, Bucket: s3-editor-source-bucket }
editor-localstack       | 
editor-article-store    | S3 object stored: { Key: 54296/ca86e420-c874-4f7a-8004-cde840f1e401/elife-54296.xml, Bucket: s3-editor-destination-bucket }
editor-article-store    | Asset stored in Db: { _id: 605b16f1c64aa161805fb99b, Key: 54296/ca86e420-c874-4f7a-8004-cde840f1e401/elife-54296.xml }
editor-article-store    | Article XML stored: { ArticleID: 54296, Version: r1 }
editor-article-store    | S3 object stored: { Key: 54296/3a6994ad-8912-4c1a-bde8-200b59117c0c/elife-54296.pdf, Bucket: s3-editor-destination-bucket }
editor-article-store    | Asset stored in Db: { _id: 605b16f1c64aa142475fb99d, Key: 54296/3a6994ad-8912-4c1a-bde8-200b59117c0c/elife-54296.pdf }
editor-article-store    | S3 object stored: { Key: 54296/de4fe28a-0d26-4353-b4e3-101ce85eace7/elife-54296-fig1.tif, Bucket: s3-editor-destination-bucket }
editor-article-store    | Asset stored in Db: { _id: 605b16f1c64aa1791d5fb99e, Key: 54296/de4fe28a-0d26-4353-b4e3-101ce85eace7/elife-54296-fig1.tif }
editor-article-store    | S3 object stored: { Key: 54296/de4fe28a-0d26-4353-b4e3-101ce85eace7/elife-54296-fig1.jpeg, Bucket: s3-editor-destination-bucket }
editor-article-store    | Asset stored in Db: { _id: 605b16f1c64aa1572a5fb99f, Key: 54296/de4fe28a-0d26-4353-b4e3-101ce85eace7/elife-54296-fig1.jpeg }
editor-article-store    | SQS - S3 upload event successfully consumed - { Key: elife-54296-vor-r1.zip, Bucket: s3-editor-source-bucket }

Let me know if there are any other logs that might be helpful.

[NuclearRedeye]

Thanks for the feedback @NateWr, I think you're now hitting the issue that if the containers aren't destroyed between runs the images stop working (which I also get locally!). You can if you like confirm that by using docker-compose rm to clean the containers and then start it up again and hopefully the images work! I'm going to raise a new issue to cover this problem, and take a look at it shortly.

[NateWr]

Oddly, I'm now back to the 403 response. I'd already used docker-compose rm, but here's the output:

 ~/Projects/pkp/libero/editor   fix/image-signing-mismatch  docker-compose rm
No stopped containers
 ~/Projects/pkp/libero/editor   fix/image-signing-mismatch  docker-compose up
Creating editor-mongo      ... done
Creating editor-localstack ... done
Creating editor-article-store ... done
Creating editor-client        ... done
Creating editor-nginx         ... done

It looks like the application is attaching AWS credentials to the GET request. Here's the request that returns a 403 response:

{
	"GET": {
		"scheme": "http",
		"host": "localhost:4566",
		"filename": "/s3-editor-destination-bucket/54296/64881206-5822-4aec-97a0-6adf768d35df/elife-54296-fig1.jpeg",
		"query": {
			"X-Amz-Algorithm": "AWS4-HMAC-SHA256",
			"X-Amz-Credential": "test/20210324/us-east-1/s3/aws4_request",
			"X-Amz-Date": "20210324T112520Z",
			"X-Amz-Expires": "3600",
			"X-Amz-Signature": "eae919ad996a35aa00c4b47209110e14d92368b2a89317f6a1337b352bfed343",
			"X-Amz-SignedHeaders": "host"
		},
		"remote": {
			"Address": "127.0.0.1:4566"
		}
	}
}

And if I remove the query params and resend the request, it returns a 200 response:

{
	"GET": {
		"scheme": "http",
		"host": "localhost:4566",
		"filename": "/s3-editor-destination-bucket/54296/64881206-5822-4aec-97a0-6adf768d35df/elife-54296-fig1.jpeg",
		"remote": {
			"Address": "127.0.0.1:4566"
		}
	}
}

Any idea what would be adding those query params?

[NuclearRedeye]

@NateWr I've not looked at it in any detail, but my hunch is that this is where those credentials are added to the request.