CORS domain in Emulators (run at GitPod)

[tachibana-shin]

[REQUIRED] Environment info

firebase-tools: 11.3.0

Platform: Linux - GitPod

[REQUIRED] Test case

Error cors domain with function signInWithEmailAndPassword

[REQUIRED] Steps to reproduces

1. Init project use firebase, firebase emulators
2. Open with GitPod
3. Run firebase emulators:start
4. Call connectAuthEmulator(auth, \https://${port}-${process.env.GITPOD_WORKSPACE_ID}.${process.env.GITPOD_WORKSPACE_CLUSTER_HOST}`)`
5. Open page with GitPod Preview (Example: https://5173-tachibanash-fcanvasedit-2t27igr91jo.ws-us54.gitpod.io/sign-in)
6. Call signInWithEmailAndPassword

[REQUIRED] Expected behavior

Throw error user not exists by signInWithEmailAndPassword

[REQUIRED] Actual behavior

Throw error Access to fetch at '...' from origin '...' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[yuchenshi]

@tachibana-shin Thanks for the report! I'm actually surprised to see these errors given that the Auth Emulator does support CORS on all domains reflected. This may be related to how GitPod proxies the request. Would you mind exporting the network requests captured from the Network tab? Please make sure to capture the failed request and any CORS pre-flight requests. You can also right click and save a HAR file as needed.

If the request capture contains sensitive information that you do not want to publish, also consider reaching out to Firebase Support and share privately over there.

[tachibana-shin]

this HAR: https://filebin.net/tkppq4fdp17cw8wy/5173-tachibanash-fcanvasedit-sezqurpgd2w.ws-us54.gitpod.io.har

[tachibana-shin]

I don't think this has to do with GitPod because when I try to access by browser, the Request is successful while I use fetch it continues to fail

[tobilen]

cors header set by the auth emulator is not *, here is a screenshot of the request when calling it in a local environment:

on gitpod, i get this:

[yuchenshi]

I think we have two separate issues here.

@tachibana-shin According to the HAR file, the response reverse proxied by Gitpod was 401 with no CORS related headers. I've tried to replicate your exact request (Copy as cURL) but issued it directly against the Auth Emulator (http://127.0.0.1:9099/) instead of Gitpod and got 204 no content and the correct headers. The screenshots from @tobilen This means issuing the request directly against the Auth Emulator v.s. reverse proxied by Gitpod gives different results -- please reach out to Gitpod and see if you can get help there.

when I try to access by browser, the Request is successful while I use fetch it continues to fail

CORS preflights / headers are only used when the request is across different origins, e.g. from your website (https://5173-tachibanash-fcanvasedit-sezqurpgd2w.ws-us54.gitpod.io in your case) to a different domain (https://9099-tachibanash-fcanvasedit-sezqurpgd2w.ws-us54.gitpod.io in your case), usually through fetch or XHR. If the latter URL is directly accessed through the browser, it is a same-origin request and the whole discussion about CORS doesn't apply. It is entirely possible that Gitpod is reverse-proxying same-origin normal requests correctly but fails to handle CORS prefetch (i.e. HTTP OPTIONS) correctly. This is outside the scope of this GitHub repo and I'd suggest reaching out to Gitpod.

---

@tobilen The Auth Emulator "reflects" the origin of the request instead of setting it to *. That is to say, your first screenshot has response header Access-Control-Allow-Origin: http://localhost:3000 because the request has header Origin: http://localhost:3000. If your request comes from a different origin, the Auth Emulator response will change accordingly and allow any origin. This is a slightly different implementation than *, but should work for most of the cases. If somehow it did not work for you, please let us know.

While I'm not familiar with Gitpod, I don't think the reflected header value is the cause here -- because that does not explain the 401 status code in your second screenshot. A more likely hypothesis is that the response is not reverse proxied but just created by Gitpod for reasons beyond my knowledge.

[google-oss-bot]

Hey @tachibana-shin. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@tachibana-shin if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.