Allowed CORS Origins form: how to use properly? Curious about CORS errors.

[matthewbcool]

Is this the expected result for the comma-separated list of origins for CORS access? Is it necessary to include all of these strings in the list?

What is the proper format here? I've taken a look at #2890

If I delete this list, the cloud runs without any cors errors but why are the url's indicated in the error list not whitelisted given the above list?

Ultimately trying to test a feature that requires fetching from an external api and I would like to whitelist it here as well.

I've tried:
-Disabling all browser extensions
-restarting the server/refreshing browser
-taking the cloudformation offline/online
-deleting browser caches and session information
-several variations of the comma separated list. (no spaces, order of domains, format changes)
-reproducing it in another instance (was able to reproduce)

[robinkwilson]

Thanks for the detailed explanation!

Hmmm, the external api needs to include the "Access-Control-Allow-Origin" header in the response.

For example, https://my-hub.com makes a request to https://i-heart-my-api.com (or any request). https://i-heart-my-api.com response needs to have Access-Control-Allow-Origin: https://my-hub.com in the header of the response.

For a recent project of mine, using Socket.io on my local environment. The reason I need the "Access-Control-Allow-Origin" header is because my server is running on http://localhost:3000 and hubs is running on https://hubs.local:8080 or https://localhost:8080.

In my server code, I configure my socket to include the "Access-Control-Allow-Origin" header, looks like this:

let io = require('socket.io')(http, {
  cors: {
    origin:
      'https://hubs.local:8080',
  },
})

Or if you use node.js + cors:

const express = require('express');
const app = express()
const cors = require("cors")
// More configuration options for cors from: https://www.npmjs.com/package/cors#configuration-options
app.use(cors({origin: true})) // includes the header `Access-Control-Allow-Origin`and assigns it to the url origin of the request

Hope this helps!

[matthewbcool]

Thanks for checking this out. Still a bit confused:
I'm running myhubscloud.com. I run my local client against myhubscloud.com with npm start- no problem, no cors errors. I have not used the Allowed Cors Origins form. (blank)

When I enter the main domain, link domain, and internal domain into the 'Allowed Cors Origins' form - just those no other external apis are called- I should expect there to be no problem running npm start and running this locally against myhubscloud.com. Correct?

If we need to manually configure these ourselves, what is the purpose of the Allowed Cors Origins field?

[robinkwilson]

Can you give me more context on when you're seeing these errors and what your environment looks like?

I thought you were accessing an external service, but now I'm confused. You may need to add your ip address to that list... but I've never had to.

That field is used so your instance can safely access expected external websites. For example, I want to get data from https://i-heart-my-api.com/ or download something from sketchfab or another website. It's a common safety measure for websites, we're giving you a way to add other websites to it. The way that field is implemented, it rewrites all existing allowed cors origins, that's why if you're adding another website, you need to add the existing domains (link, internal, main etc). It's a todo to have that included.

[matthewbcool]

That's super useful to know my expectation of what the form should do is correct, and you gave me the clue I needed: "rewrites all existing allowed cors origins"

Given that the form should rewrite all existing allowed cors origins, I would expect adding just the existing domains (link, internal, main etc) and adding nothing else should not result in any cors errors.

Here is the fix:
no spaces between comma separated domains.
just use the address- no need for the 'domain.com' format
no need for internal domain if it's the same as your main
whitelist localhost for testing locally

https://main.com,https://link.com,https://localhost:8080
Using that format above makes the form work as I would expect 😁. Of course we can then add whatever external api we are hitting to the end of that right? I tried so many different combinations to figure this out!

[jbshin-gemiso]

This article has been of great help to me.

While developing a custom client, it was not possible to connect to https://localhost:8080 and test it. However, if I add https://localhost:8080 to the allowed CORS origins item as above, it works normally.

thank you. Have a nice day.

[AVTPJ]

Can someone confirm the format of the domains? Do you need to include protocol (i.e. https://)? Are wildcards allowed? Been trying to do some testing but it's difficult when you don't know the exact format required.