CORS issues during SSR

[itssumitrai]

This is kind of similar to #8314

Currently, the universal fetch in Sveltekit forces the same behavior as on the client side. While this sounds a good idea, its not as good as it sounds.

Firstly, there is no CORS on server side. All the requests should work with mode: no-cors but the universal fetch would return an empty body response which is not useful at all.

With the isomorphic load and handleFetch hook,
The way it should work is, you make a request to your client endpoint (for sharding requests) lets say https://client.xyz.com
And then with handleFetch, you can rewrite to directly your backend host alias and with http instead of https as its server to server. Now the logical thing would be to use mode: 'cors' for client and use mode: no-cors for the server to server request.
But we can't do that because we would get an empty body response.

Secondly, when there are k8s or any other deployment architecture, the event.url.origin might have the cname of the k8s like panda.production.k8s.xyz.com, but the user facing hostname is going to be something else like panda.xyz.com

This creates another CORS issue on server side, as due to the previous issue we have use mode: cors on server side fetch. Now, the BE endpoints would have Access-Control-Allow-Origin: panda.xyz.com header and Sveltekit fetch uses the origin for all the CORS matching, here origin is panda.production.k8s.xyz.com which doesn't match and you'd get a CORS issue on the server side.

The only way I have figured out around this issue is to forcibly overriding the event.url.origin to the actual user facing hostname.
IMO, the universal fetch should be allowing mode: no-cors on server as there is no CORS concept on server

[Br1tBreaker]

bro

It sounds like you are encountering some difficulties with using universal fetch in Sveltekit, particularly with regards to handling CORS issues on the server-side.

One solution you have suggested is to use mode: 'no-cors' for server-to-server requests, but this results in an empty response body. Additionally, you have noted that the event.url.origin may not match the user-facing hostname, which can cause additional CORS issues.

One possible solution to these issues is to explicitly set the Access-Control-Allow-Origin header on your backend API to include both the event.url.origin and the user-facing hostname. This can be done using a middleware function or by modifying your backend API directly.

Another approach is to modify the event.url.origin to match the user-facing hostname before making the request, as you have suggested. However, this may not be the best approach if you need to handle multiple user-facing hostnames.

Regarding the use of mode: 'no-cors' on the server, it is true that CORS is not a concept on the server-side, but using mode: 'no-cors' can result in an empty response body. One alternative is to use mode: 'same-origin' on the server-side, which should allow the request to go through without triggering a CORS issue.

Ultimately, the best solution may depend on your specific use case and requirements. It may be worth experimenting with different approaches and consulting the Sveltekit documentation or community for further guidance.

[itssumitrai]

One possible solution to these issues is to explicitly set the Access-Control-Allow-Origin header on your backend API to include both the event.url.origin and the user-facing hostname. This can be done using a middleware function or by modifying your backend API directly.

Are you saying you want to put all the randomly generated cnames for kubernetes in the BE api ? If you are talking about just dynamically adding that through looking at a header or something, then that would create a security issue where attackers can simply pass those headers to get access to CO requests

Regarding the use of mode: 'no-cors' on the server, it is true that CORS is not a concept on the server-side, but using mode: 'no-cors' can result in an empty response body. One alternative is to use mode: 'same-origin' on the server-side, which should allow the request to go through without triggering a CORS issue.

In case you didn't know same-origin is only for requests on same origin, any other origin would throw an error. So you can't make a request to your BE apis using it which would have a different origin.

I think Sveltekit relies too heavily on event.url.origin, and there is no way to modify that value apart from hacking seems like