Why do public GSN relayers have CORS limitations?

@k06a asked on Telegram:

Hey guys! Why public GSN relayers have CORS limitations?

Access to XMLHttpRequest at ‘https://kovan-01.gsn.openzeppelin.org/’ from origin ‘http://localhost:8101’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

It seems to me that this is a bug and the response should include a wildcard Access-Control-Allow-Origin header.

It should be reported to https://github.com/openeth-dev/gsn.

1 Like

@k06a has created an Issue: https://github.com/openeth-dev/gsn/issues/288

Hey @k06a, thanks for reporting this! The GSN relayer does have an Access-Control-Allow-Origin header set to * (see here). Also, when I curl the getaddr endpoint, I can see the header being set.

$ curl -v 'https://kovan-01.gsn.openzeppelin.org/getaddr'
< HTTP/1.1 200 OK
< Server: nginx/1.14.0 (Ubuntu)
< Access-Control-Allow-Headers: Content-Type, Authorization, Content-Length, X-Requested-With
< Access-Control-Allow-Methods: GET, OPTIONS
< Access-Control-Allow-Origin: *
* Connection #0 to host kovan-01.gsn.openzeppelin.org left intact

Could you share a minimal example of the code that reproduces this issue? If you could also share the addresses of the contracts involved, that’d also save some time. And finally: do you experience the same problem in Rinkeby or Ropsten?

1 Like