https://serverless-stack.com/ logo
Join Slack
Powered by
If you have CORS set to TRUE on an Api, you still ...
# sst
p
If you have CORS set to TRUE on an Api, you still can't use resources across domains because you need to add an OPTIONS route to return 200 and the relevant CORS headers. Would it be worth SST generating default OPTIONS routes and handlers?
r
Is that right? I think you just have to return the correct headers on the response.
p
On the post route we had the correct headers but the preflight options check was returning a 404. Adding a simple options route + handler got it working.
r
That's odd. I've never specifically added a route for options and I've never had a problem, browser or via postman/equivalent
p
Maybe there is something else wrong and what I've changed has made it work accidentally? I'm definitely no expert on CORS - I tried/guessed at a bunch of things before I came up with trying that and had it work.
f
Yeah you shouldn’t need an OPTIONS route. If CORS is enabled (enabled by default for 
sst.Api
), OPTIONS request is handled automatically by API Gateway.
You can override the default behaviour by adding ur own OPTIONS route.
Btw, @Phil Astle do u have an 
ANY
or 
$default
route configured? I wonder if they are intercepting the OPTIONS request 🤔
p
Nope, no ANY or $default routes.
We did have an issue with how we were defining routes which meant we couldn't override where an authenticator was added, but I can't see how that would have caused an issue with this. We basically had our routes defined like the below with a default authorizer and type set:
Copy code
"GET /google/oauth-callback": {
          handler: "src/graph/site_reviews/google/oauth-callback.handler",
          permissions: [auroraClusterPolicy, auroraSecretPolicy],
          authorizationType: ApiAuthorizationType.NONE,
This doesn't work however - it ignores the authorizationType property. We had to change the route to this:
Copy code
"GET /google/oauth-callback": {
          function: {
            handler: "src/graph/site_reviews/google/oauth-callback.handler",
            permissions: [auroraClusterPolicy, auroraSecretPolicy],
          },
          authorizationType: ApiAuthorizationType.NONE,
        },
This then caused it to ignore the default auth. This does make me wonder though... Could the default auth we defined have been affecting the undefined OPTIONS route, which is why it started working when I added a specific OPTIONS route which explicitly turned off the auth?
f
Thanks for the details Phil. Just to clarify:
This then caused it to ignore the default auth
Isn’t that what you intended to do by setting the authorizationType to 
ApiAuthorizationType.NONE
?
Could the default auth we defined have been affecting the undefined OPTIONS route?
It shouldn’t. CORS is configured by HTTP API internally. OPTION routes aren’t added explicitly and hence not affected by the default auth.
If you get a chance to create a sample repo with just an Api with 1 route that reproduced this issue. I can give it a try on my end 🙂
p
Isn’t that what you intended to do by setting the authorizationType to 
ApiAuthorizationType.NONE
?
It is what we wanted but we didn't expect to have to declare the route differently to get it to accept the authorizationType override 🙂
If you get a chance to create a sample repo with just an Api with 1 route that reproduced this issue. I can give it a try on my end 🙂
Should be able to do that (and the other one) sometime this week or next week hopefully, now we're in a cooldown!
Open in Slack
PreviousNext
Powered by