I had a basic message api that I set up a while ago and I am returning to it to fork it into a different direction. I forked it, and then upgraded the socket.io library to 3.0.0. However, when I attempt to connect to it from my localhost server via javascript I get this error.
Access to XMLHttpRequest at ‘GLITCHURL’ from origin ‘LOCALURL’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
If I revert my socketio request and connecting url back to the original project then this error goes away and I can see the ‘client connected’ message in the Logs. I also remixed the project again and tried connecting to that to see if it had something to do with legacy projects but that 2nd remix still worked.
Below is the code I am using to spin up the socketio server. I have tried a few different versions but they all seem to cause the same error message.
var server = require("http").createServer();
var io = require("socketio")(server, { origins: "*:*" });
io.sockets.on("connection", socket => {
console.log("Client has connected!");
console.log(socket.id);
});
console.log("Server started.");
server.listen(3000);
What is the definition of a proxy site? I want to make sure I am not breaking any TOS. My plan was to use glitch to host the node.js/socket.io server and have everything else hosted on my dedicated server. Is that considered a proxy site?
It is weird that the previous version of socket io still works. Was it grandfathered in or something?
A proxy site is a site that no one knows you are on and also can’t be tracked. Useful for bypassing censorship and that stuff because extensions don’t work
is my local development server triggering the CORS issue then? Should the issue go away if I upload it to a proper domain? Or do I need to set the origins to be a dedicated url?
I tried removing the , { origins: "*:*" } from the project but I get the same behavior. io 3.0 fails but 2.3 succeeds.
I have a feeling this has something to do with io 3.0 change that is triggering something AWS/Glitch does not like.
It looks like they have integrated cors into the framework. However, if I were to add these cors values that would trigger the glitch TOS violation right?
This has been argued before, but I don’t think because CORS can be used to create proxies, I don’t think it necessarily means AWS/Glitch bans using CORS. If that was the case, most APIs and Express projects created on Glitch should have been banned/suspended and CORS is used very often on Express apps.
I think the *:* thing might be an issue (maybe versions before 3.0.0 did something different with that). The format for CORS-related options also changed slightly: https://socket.io/docs/v3/migrating-from-2-x-to-3-0/#CORS-handling (not sure if passing origin as a top-level options still works).
There’s actually nothing banned. I received similar responses from Jenn and Tasha, and I believe it has been wrongly associated with the ban of a particular package named cors-anywhere. (Because the name ‘cors’ is present in that package, it was assumed that CORS was also banned)
