Issue : - Frequent CORS Errors which Dev's building on wasp are getting

[0xTaneja]

Description

closes #2933

Select what type of change this PR introduces:

1. Just code/docs improvement (no functional change).
2. Bug fix (non-breaking change which fixes an issue).
3. New feature (non-breaking change which adds functionality).
4. Breaking change (fix or feature that would cause existing functionality to not work as expected).

Description

Many users deploy a Wasp app, hit the client, and see CORS error in the browser console even though the real cause is a missing env-var or other 5xx on the server.
This happens because the response that bubbles up from a crashed server has no Access-Control-Allow-Origin header, so the browser rewrites the failure as a CORS issue and hides the actual JSON body.

I maybe wrong on the issue but the only problem regarding the CORS which i found out in our codebase was it,

[infomiho]

Hey @0xTaneja thank you for the contribution.

I think this might be going too loose with security because we are effectively disabling CORS for all endpoints for all of our users. We want to be explicit in which domains we allow to connect to our server. Setting the value to * allows any client to connect to our server (which is usually fine but we don't want that by default). Users can do this themselves by modifying the global middleware.

I'd like us to more explicitly solve #2933 by doing something like this:

• we already have / that returns 200 and an empty body
• we can add Access-Control-Allow-Origin: * for only that endpoint
• we can ping the server at / when there is Network error on the client, so we can output something in the browser e.g. Hey, it seems like the client can't connect to the server - the server is probably not running or the client is trying to connect to the wrong URL. If the URL looks correct XXX, check the server logs to debug.
  • I'd be as precise as possible here and try to output it only Network errors if possible.

This is a rough idea, I'm not 100% about this, but I'm trying to give you an idea how we'd like the DX to look like.

[0xTaneja]

yep i agree with you @infomiho i have added Access-Control-Allow-Origin: * globally but i can make it to that particular endpoint.
pinging could be an option
and also one more thing maybe we can do is validate things like if required env's to make the app run are missing, i know we are doing this on haskell side but maybe if we can do this on server side as well then we can throw the error !!
another thing i suggest is /health route as well just to check things are good for db and env's stuff, and in deploy documentation maybe tell users to check /health route when they get error !!

[Martinsos]

yep i agree with you @infomiho i have added Access-Control-Allow-Origin: * globally but i can make it to that particular endpoint. pinging could be an option and also one more thing maybe we can do is validate things like if required env's to make the app run are missing, i know we are doing this on haskell side but maybe if we can do this on server side as well then we can throw the error !! another thing i suggest is /health route as well just to check things are good for db and env's stuff, and in deploy documentation maybe tell users to check /health route when they get error !!

Validating required envs -> we are actually doing this on the server side now also since recently if I am correct, check out https://wasp.sh/docs/project/env-vars#custom-env-var-validations -> we will run those checks on server start, and if a deployed server is missing env vars, it will fail with useful error message! Right @infomiho ? That said hm, I guess that error message will be logged up there into the logs on the hosting provider, and you might still be getting CORS errors from the client perspective. So that helps if you go there to see what the issue is, but you still need to konw that CORS error might not be CORS error.

@infomiho pinging idea makes general sense to me -> by checking / or /health or sometihng we can check if server is running or not, so if it is not, we can make it clear that is the real error, not CORS. Although we have to then do that check on CORS errors hm, sounds a bit weird to be performing such extra checks in production, but if it works ... .

I wonder if there is some other way to go around all this? So first of all, why do we get CORS errors if server crashed / there is some 500? @0xTaneja said the following:

This happens because the response that bubbles up from a crashed server has no Access-Control-Allow-Origin header, so the browser rewrites the failure as a CORS issue and hides the actual JSON body.

If that is correct, would the solution be adding Access-Control-Allow-Origin header onto errors, so that they properly get through? We still wouldn't be doing it for all respnses from our server, so no global *, but only for these error response so they get properly through? Am I talking nonsense or is this doable?

Additionally:

• We don't really have a standard way to do a health check. I know we discussed it multikple times but never ended up on a solution. I think we concluded users can add it on their own, but maybe indeed we should have something of our own hm. Still not sure, I can see people wanting to remove in case we add it.
• Could we provide people with better default CORS story? We know the URL of the client anyway, we could set CORS to that as a deafult setting? But ok this is story for another issue (I added it to another CORS issue right now).