Cors issues - ThreeIDProvider.create()

Getting CORS errors when trying to instantiate my ceramic object using threeId - was working until I upgraded from 1.X versions of http-client/packages to latest 2.x versions. Here’s my daemon.config.json:

{
  "anchor": {},
  "http-api": {
    "cors-allowed-origins": [
      ".*"
    ],
    "admin-dids": [
      "did:key:z6Mkg8w5QXBon7hukP23in4dhVtPwZBSd3F87iDCbyx8PTjk"
    ]
  },
  "ipfs": {
    "mode": "remote",
    "host": "http://localhost:5001"
 },
  "logger": {
    "log-level": 2,
    "log-to-files": false
  },
  "network": {
    "name": "mainnet"
  },
  "node": {},
  "state-store": {
    "mode": "fs",
    "local-directory": "/catalystdrive/ceramicstate1"
  },
  "indexing": {
    "db": "sqlite:///home/bitnami/.ceramic/indexing.sqlite",
    "allow-queries-before-historical-sync": true,
    "models": []
  }
}

Looks like the post request to https://ceramic-node.vitalpointai.com/api/v0/streams is failing. Interestingly, if I send the payload that it’s trying to send using something like Thunderclient - it works, just not from the browser.

Also works fine if I use just the key-did-provider.

1 Like

Hey Aaron, I just added this question to our triage list, will have an engineer reply and help debug. Thanks!

Thanks not sure if it helps but noticed a recent version of cli added authorization to the headers (Access-Control-Allow-Credentials I think?) As per the error, wondering if that conflicts with the wildcard origin setting.

Aaron, great eye. @ukstv can you take a look since you made the header change?

Reported above that it was working with key-did-provider - I was mistaken, same issue there too.

I believe I’ve got this sorted out. My node was setting its own Access-Control-Allow-Origin “*” in its config separate from the ceramic daemon config. Removing it from the server config seems to have eliminated the CORS issues I was having above. Think you can mark this a solved for now unless I encounter some other side effect resulting from the change.

Thanks.

3 Likes

FWIW, I was seeing a similar issue

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:7007/api/v0/streams. (Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’)

in version 2.16, and upgrading to 2.20 resolved it.