samvera / serverless-iiif

IIIF Image API 2.1 & 3.0 server in an AWS Serverless Application
https://samvera.github.io/serverless-iiif/
Apache License 2.0
69 stars 21 forks source link

Accessing Image Manifest #103

Closed JoshuaAPhillips closed 1 year ago

JoshuaAPhillips commented 1 year ago

Hello all,

This may be a rather elementary question/issue, but I'm having problems accessing a test image manfest. The image in question is here: https://digital-anon-facsimiles.s3.eu-west-2.amazonaws.com/m48-1-test.tiff but I cannot seem to access a manifest for it using the suggested pattern in the Source Images section of the readme. I've been trying variants on the following: https://digital-anon-facsimiles.s3.eu-west-2.amazonaws.com/iiif/2/m48-1-test/info.json but haven't been having much luck.

Also, when I use the CloudFormation endpoint in place of the S3 bucket URI (i.e., https://dm2vkd8jzjuqr.cloudfront.net/iiif/2/m48-1-test/info.json) I get the following error message: InvalidARN: ARN accountID does not match regex "[0-9]{12}".

I'm probably missing something very basic but am new to AWS... Thanks in advance! Josh

mbklein commented 1 year ago

Hello @JoshuaAPhillips,

The default S3 key pattern for TIFF files is %s.tif (note the single f on the end of the file extension). If you rename your test file to m48-1-test.tif and make sure that your serverless-iiif stack was created using digital-anon-facsimiles as the SourceBucket parameter, you should then be able to load your image via the CloudFront endpoint (i.e., https://dm2vkd8jzjuqr.cloudfront.net/iiif/2/m48-1-test/info.json).

mbklein commented 1 year ago

You could also resolve this by redeploying the application and setting the ResolverTemplate parameter to %s.tiff – that parameter tells the application how to find your files relative to the root of the SourceBucket, with %s taking the place of the image's ID. But renaming the file in the bucket is probably the quicker and easier solution.

JoshuaAPhillips commented 1 year ago

Hello @mbklein, thanks for this - it's worked perfectly for this one test image. I've been able to access a manifest which is accessible through the Digital Bodleian's IIIF manifest editor tool. However, I've tried a couple of other test image. While the server generates manifests for both that are accessible through the URI, when I put them into the same tool they don't resolve.

The URIs are: https://dm2vkd8jzjuqr.cloudfront.net/iiif/2/m48-2-test/info.json https://dm2vkd8jzjuqr.cloudfront.net/iiif/2/m48-3-test/info.json

Is this something you might be able to help with?

mbklein commented 1 year ago

There's at least one and possibly two things going on here – one is a software issue, while the other is an issue of terminology.

If you're trying to submit https://dm2vkd8jzjuqr.cloudfront.net/iiif/2/m48-2-test/info.json to the IIIF manifest editor as a manifest to open, that's not going to work. The info.json file isn't a presentation manifest; it's an image information document.

If you're trying to create a new manifest or add this image to an existing manifest, then there's a separate issue going on – your web browser is refusing to load the image information because it's failing its CORS preflight check. It's a lot to explain if you're not already familiar with CORS, but because of the type of request the manifest editor is making, it's expecting a response from the server that isn't matching. This is definitely something we can (and should) fix in the IIIF server's code, but I'm going to have to consider the best way to make the (minimal) security implications clear to those installing the server.

Thanks for bringing this to my attention, and please keep an eye out for a fix.

JoshuaAPhillips commented 1 year ago

Thanks for this reply. I've been doing the latter: creating a new manifest and adding the info.json link as a canvas in that manifest. Curiously, this seems to work from my laptop, but not from my desktop and from what you've said I suspect it's because I modified CORS on my laptop's browser a while back.

I'd be very grateful indeed if you could keep me posted about any possible changes or fixes.

All best, Joshua

mbklein commented 1 year ago

I've just submitted a PR to address this issue. See #107. After it's reviewed and merged, I can release a new version of the app to AWS and you should be able to upgrade fairly easily.

JoshuaAPhillips commented 1 year ago

Thanks for letting me know! I'll keep an eye out for the upgraded AWS app. Best, J

JoshuaAPhillips commented 1 year ago

Hi @mbklein, just playing around with the re-deployed the AWS app and it seems to be working perfectly now: thank you so much for your help! Thanks again, and all best, J

mbklein commented 1 year ago

Sure thing! I noticed a small bug in the deploy template after release, and it's been patched and published now. No immediate need to update if it's working for you, but you might want to make sure you're on at least v4.3.2 at some point just to stay current.