Js-ipfs: Preload generating CORS errors in console

[mitra42]

• Version: 0.30.1 pulled from GIT git://github.com/ipfs/js-ipfs.git#bffe080cd6c3fa202ca0437f8abe38dca75e5903
• Platform: Mac / Chrome
• Subsystem: preload

Type: Bug

Severity: unsure - probably

Description: preload is failing with CORS errors

Steps to reproduce the error:

I'm loading one of my existing demos, but am seeing repeated

Failed to load https://node0.preload.ipfs.io/api/v0/refs?r=true&arg=zdj7WiLc855B1KPRgV7Fh8ivjuAhePE1tuJafmxH5HmmSjqaD: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

I'm not intentionally preloading anything, but I noticed some messages about preloading pass by the lists recently, so I assume something changed.

The demo is broken, I don't think that's IPFS's fault, but it might be and given the closeness to the summit I thought someone might want to know.

[alanshaw]

Fixed here https://github.com/ipfs/js-ipfs/issues/1459#issuecomment-408654621 and in https://github.com/ipfs/js-ipfs/pull/1475/commits/4e50e70c2c5f52b231725d8cd7054f6158136258

[parkan]

this seems to come back intermittently, any ideas?

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=zdj7WkiVdkzBK8ponzCkE17CJdpsrxs28PGCTTuDPbhgCCXjg. (Reason: CORS request did not succeed). 

[alanshaw]

I believe this could still occur if the preload nodes are down. @lgierth is still true?

[parkan]

a scenario I've seen is when a service behind nginx, rather than nginx itself, generates the CORS headers, and that service goes down, we end up with nginx-generated messages without the right CORS (which then masks the underlying service failure)

could that be happening here?

[ghost]

By now nginx should be doing the CORS headers exclusively though, and go-ipfs shouldn't be setting them anymore.

I'll double-check this tomorrow.

[mitra42]

@lgierth - do you mean just for this (preload) case, or for all cases. Because we've also got an open bug where go-ipfs running locally (on a laptop) is denying access to local browser. https://github.com/ipfs/js-ipfs-api/issues/855

[ghost]

Just talking about the preload.ipfs.io and ipfs.io cases, but I'll check that /version issue out too

[patientplatypus]

Seconding this problem - no idea why this is happening, but I've tried several different methods (see: https://gist.github.com/patientplatypus/a4adc9d1ae69fa7b3c67843ae8bab935) and I keep getting CORS errors. My code was working prior and I didn't change anything. I think this is a bug.

Here is the error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=QmcB5MvGmETQUQYeTbqd42HuN3kh1AReHwpk9BE45BXAMt. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node0.preload.ipfs.io/api/v0/refs?r=true&arg=QmcB5MvGmETQUQYeTbqd42HuN3kh1AReHwpk9BE45BXAMt. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=QmcB5MvGmETQUQYeTbqd42HuN3kh1AReHwpk9BE45BXAMt. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]

I have allow origins * in my config, so I don't think it can be client side...

[mitra42]

Just confirming this preload/CORS issue is still happening.

Although this might not be a CORS problem since its returning a "502 Bad Gateway" response, which (because it doesnt have cors headers) generates a cors error.

[mitra42]

The exact string is https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=zdj7WePre4jBSvoCyAZQHJUCk7Jqin4fwGNKeMNE7st9Brebh

[daviddias]

This has been fixed (AFAIK). Let us know if not, closing for now.

[lifeBCE]

@diasdavid Can you point me to the tag or hash that has this fixed? I just tried 0.33.0-rc3 and it still exhibits all errors reported. 502 gateway, CORS and preload errors.

I tried to run the latest RC because I woke up this morning unable to communicate to the IPFS network at all in my app. Seems none of the bootstrap nodes will allow proper communication due to these errors.

[mitra42]

I'm certainly still seeing this as well.
@diasdavid is the required fix client-(JS) side or server (go) side ?

[daviddias]

@mitra42 I believe there were multiple hiccups on IPFS Infrastructure recently, but I'll let the @ipfs/infrastructure team confirm.

If you see a CORS issue, it always means that the endpoint (in this case the go-ipfs node) doesn't have CORS enabled. CORS is a Browser protection but that gets set by the "server" part to avoid getting servers contacted from browsers on domains that are not whitelisted.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS explains CORS very well.

[mitra42]

@diasdavid - I'm familiar with CORS. CORS problems I've seen have been either "client" or "server" (Go-IPFS node) side, if the client didn't add the right "Origin" headers it can cause problems, or it could be the server not properly responding to that header.

If its a server problem, as you suggest, then this issue should probably be re-opened, because as of yesterday some of your default preload servers don't have CORS enabled.

[daviddias]

@mitra42 I opened a issue on the IPFS Infrastructure, check progress here https://github.com/ipfs/infrastructure/issues/447

[Rkrushanovskij]

Hi there!
I tried out to call ipfs` api directing to localhost but faced CORS error. I did CORS` guide from js-ipfs-api README.md, but it wasn`t fixed.
Here is my ipfs config API.HTTPHeaders.Access-Control-Allow-Origin:

[
  "http://localhost",
  "http://127.0.0.1"
]

(also i tried to set without http://, with port, only localhost and only 127.0.0.1 - same results)
can you help me?
Also i`ve tried to connect to some addresses from my ipfs bootstrap list - but it results with:
net::ERR_NAME_NOT_RESOLVED to dnsaddr;
net::ERR_INVALID_HTTP_RESPONSE to ipv4 addresses;
net::ERR_ADDRESS_UNREACHABLE to ipv6 addresses.
It is not related to topic but hope someone can help me anyway...