Need help with enabling CORS


#1

I’ve got a Jets deployment with config.cors = true…as the documentation states, the deployed api on API Gateway is created to respond with various headers including Access-Control-AllowOrigin = ‘*’. Unfortunately my requests get rejected at the browser still.
I’m no CORS expert, far from it, but all documentation I can find says the header name should be Access-Control-Allow-Origin.
When I brute force that header name into the api response, everything works as expected.

Dove tailing off my comment about not being a CORS expert…is the missing hyphen in the header name Jets sets up a bug or am I doing something incorrectly?

Any assistance would be greatly appreciated.

~bb


#2

So yes, the hypen should be present. Access-Control-Allow-Origin is right and Access-Control-AllowOrigin would not work.

Thing is. Deployed a test demo Jets app. The headers seem to be set correctly as “access-control-allow-origin”:

$ curl -svo /dev/null "https://j1zu4xxhtf.execute-api.us-west-2.amazonaws.com/dev/posts" 2>&1 | grep 'access-'
< access-control-allow-origin: *
< access-control-allow-credentials: true
$ 

Here’s also a screenshot:

Unsure why it’s missing the hypen for you at the moment.


#3

First, thanks for the quick response…very much appreciated.

Second…I’ve had some oddness going on, even beyond the CORS issue. I ended with a problem where aws-sdk-core-3.46.0/lib/aws-sdk-sts/customizations.rb was not being packaged up into the lambda layer essentially killing all of my endpoints. I ended up deleting my lock file, backing down to Jets 1.5.10 and reinstalling. I’ve since settled back on Jets 1.6 and my issues are gone.
I can’t connect any of the dots to even begin to tell you what was going on … I’m sorry I wasted your time.


#4

Np. Thanks for the info actually!

This is interesting. Another person in the gitter chat room ran into the same issue. He ended up clearing is build cache and that resolved the issue. For posterity, to full clear the build cache:

rm -rf /tmp/jets

Think going to move on, but this is good to know in case there are more reports.


#5

Thanks for the tip on clearing the build cache.

So - not to beat the dead horse but it looks like I am back on the CORS thing.
Yes, following your example all appears to work.
My use case is slightly different:

  • Back End Jets deployment . MODE=api

  • Front End React App using AWS Amplify API ( Axios ) for RESTful connections.

The big difference here ends up being the initial OPTIONS request. GET for sure returns the correct headers but OPTIONS does not and this prevents the Amplify library from moving on to the GET request.

Thoughts?

~bb


#6

@balutbomber Unsure. Wondering if you could provide an example project.


#7

Oh missed the OPTIONS part. Thanks. Will dig into it.


#8

@balutbomber Fixed in https://github.com/tongueroo/jets/pull/166 Released in 1.6.2


#9

Sweet thanks @tung…I was digging through the jets code earlier and figured that was the issue but am new to ruby so kept my mouth shut :zipper_mouth_face:
So now that I’m a newb is out of the bag…next question…when will 1.6.2 make it up to rubygems.org or is there another way for me to pull it down?


#10

Never mind…looks like I got it :+1:


#11

Great. Glad you were able to get the latest version.

For others and posterity, have found that the bundler seems to take about 20m before it usually shows up. Probably the CDN settings they’re using, which would make sense.