Issue with CORS error in accessing a project locally and in the deployed studio.

Hey, I’m trying to access my project locally (the same issue happens in the deployed studio as well) and I keep getting this error. I have added CORS Origins and allowed credentials for the local path, the deployed path, and the wildcard to try and get this working, but it keeps throwing this error.

Hey User! Are you using any browser extensions that could be interfering with CORS?

I don’t believe so, my only real browser extension are Vue.js devtools and Google Tag Assistant. I work for a studio with many projects, but this is the only one where it has thrown me this error.

Can you share what your CORS origins look like in manage?

yeah for sure, I hid the deployed name for client privacy but aside from that, this is my CORS Origins section:

I attempted to add the wildcard because internal navigation on the site wasn’t work (was throwing a CORS error) and I thought that might be a way to alleviate it

but since I have done that, the entire studio now fails to load

If you run

sanity cors list

in your terminal from the Studio's root folder does it contain the domains you expect?

Yes, it containse the same values, the deployed studio, the local server, and the wildcard

Did you happen to remove the your localHost domain and then re-add it?

Hi User. I love breaking stuff and haven’t been able to recreate this. I might have some good input on your local network settings but want to double check your install method. Did you use a particular starter to get started or use the sanity cli to start a new project?
Here’s a quick shot of my results just now. I created a new directory and ran sanity init inside of it - new project, blog starter - macOS, node v16 (successful):

This is on a personal account I use, gmail auth. I was already logged into the cli.

Off the wall question… would you signup email happen to start with

idco…

at gmail?

yes, while trying to fix my initial page navigation cors error, one of my thoughts was to remove and re-add the allowed hosts. After doing this, the studio started completely erroring out.
I also haven’t exactly been able to re-create this haha! The company I work for has many clients that all use sanity as a CMS. We follow the same set up for all of our projects, yet this is the only one that it fails with. Someone else at the company actually initialized and created the studio so I am not entirely sure the steps they went through, but we have a basic starter structure that we mimic for every project and build off of. I personally initialize it on the CLI when I create the studios. And no, the signup email does not start with idco

hmm 💭 … without digging into your project information, maybe try deleting all CORS entries and re-entering

<http://localhost:3333>

- make sure there are no spaces.

I have been playing around with this messy test studio for a while, hosting environments in gitpod, codesandbox, and extra local ports with no issues yet.

I added http://localhost :* because I saw someone who posted their own support ticket say that it worked for them and that there may be an issue with removing and re-adding CORS origins, and for the time being it has fixed it! Which is great, I can continue to work on the backend of the project!
But in the near future I will have to give our company’s client a link to access it and the deployed link is still not working

that’s super funky, please follow up if it happens again - maybe there was some mystery character junk or a random spacethat got into your cors config values that wasn’t rendering in the web form.

After putting 2 and 2 together I just thought to try https://* as a wildcard replacement to get my deployed studio running and that has solved the issue for the time being.
I don’t think there are random characters or anything like that, because they were initially working. When I removed and re-added them, the dates indicating when they were initially added all pointed to the date when they were first added and working as opposed to a new date which I figure it would do if there was some special character or space making the value of the origin different.

This would be a pretty major security risk, which I’m sure you’re aware.