search

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
71 stars 24 forks source link

hello world: forbidden #12

Closed allanberry closed 4 years ago

allanberry commented 4 years ago

Hi there. I'm attempting to get to "hello world" via this serverless-IIIF project. Thanks for your work on this; I'm super excited to see it in action, and perhaps to contribute in the future.

(This might not be the right channel for support requests like this, but I imagine since this is so close to initial configuration, it's possible this may be a documentation error? It could also, of course, be an error on my part. :) If this should go elsewhere, please let me know, and apologies.)

So, I'm following the "AWS Console" instructions pretty carefully, and everything seems green, but I'm getting an error.

I have an image hosted (in an S3 bucket):

I have followed the README instructions, and have a Lambda function serverlessrepo-serverless-iiif with a big green checkmark, "Your application has been deployed". I see an "Endpoint" key with the value https://qc6j9iny34.execute-api.us-west-1.amazonaws.com/latest/iiif/2/, and the description "IIIF Endpoint URL". (I also see an "ApiId" which I am ignoring so far.) I pointed the stack at the correct bucket bcw-images; I believe I have opened the permissions in the bucket, and opened CORS.

Hitting https://qc6j9iny34.execute-api.us-west-1.amazonaws.com/latest/iiif/2/ gives an Auth error:

{"message":"Missing Authentication Token"}

Hitting https://qc6j9iny34.execute-api.us-west-1.amazonaws.com/iiif/2/test/tree/info.json, as in the README, gives an Access error:

{"message":"Forbidden"}

Same for /iiif/2/test/tree/full/full/0/native.jpg, and if I encode the slashes in the URL: https://qc6j9iny34.execute-api.us-west-1.amazonaws.com/iiif/2/test%2Ftree/info.json

Please let me know if anything obvious pops out at you. I'd appreciate any input.

allanberry commented 4 years ago

@mbklein any idea? If you recall, I asked you about this at the last Code4Lib at NU; at that point I meant to run it with Express, but this solution seems more sweet. My lack of experience with Lambda may be my undoing, however.

mbklein commented 4 years ago

@allanberry Sorry for the delayed response. It's hard to say exactly where the Forbidden error is coming from, though if you add the correct deploy stage to the URL, you get Not Found instead: https://qc6j9iny34.execute-api.us-west-1.amazonaws.com/latest/iiif/2/test%2Ftree/info.json

Do your CloudFront logs for the lambda have any information in them that may be useful?

websnacks commented 4 years ago

Hi, I was running into the same problem. But looking at the Lambda function and reading the documentation again, I noticed that the script is looking for a TIF file. But just like you I did a test with a JPG file and that's the reason you are seeing a NOT FOUND error.

Try uploading a TIF file and you will notice that it's working.

What I did was removing the file extension from the s3Object function. Here is the code:

  s3Object (id) {
    var s3 = new AWS.S3();
    console.log(this.sourceBucket);
    return s3.getObject({
      Bucket: this.sourceBucket,
      Key: `${id}.tif`
    }).createReadStream();
  }

Now you have to include the file extension in your URL and it should work.

https://qc6j9iny34.execute-api.us-west-1.amazonaws.com/latest/iiif/2/test%2Ftree.JPG/info.json

allanberry commented 4 years ago

Thank you @websnacks! That did the trick. So now these work:

Now I just have to figure out why it's so dang slooow. But thanks again.

mbklein commented 4 years ago

@allanberry I believe you might be running into the issue that was addressed in #13 (which was pending for a long time, and which I just merged). @tpendragon figured out that it wasn't the image processing that was slow; it was fetching the image dimensions. The new code looks for width and height attributes among the S3 object's metadata and uses those if present. If not, it falls back to loading the image header and retrieving the dimensions. It's resulted in a massive performance improvement on the Princeton and Northwestern IIIF servers. Try pulling the new code and redeploying (with the appropriate change to s3Object() so it can find your images), then add height and width to your images' S3 metadata and see if that helps.

allanberry commented 4 years ago

Thanks @mbklein I'll check it out (probably not for a couple of weeks). So you're saying that each time I upload an image file into my S3 space, I'll need to manually enter its dimensions as well? Does that happen in a form somewhere in S3, or should this be embedded in the file (or a sidecar) somehow?

(Again, please pardon my ignorance of Amazon infrastructure products; this is my first experience using them directly.)

allanberry commented 4 years ago

Ok, so I've done this; I tore down the original instance and recreated a new one (so I could use the deploy button in the README; I didn't have confidence in my AWS-fu to modify the source in place). At any rate, PNG works now, and pretty speedy:

TIF too:

As PNG is my primary use case, I think I'm in the clear. Regardless, @mbklein some JPGs still seem slow, despite adding width and height metadata (maybe I'm doing it wrong)... a difference in JPG encoding or something?

As a contrast, this one works nice and quick, despite manually adding no height/width metadata:

Curious. Anyways, thanks again.