CORS Errors on Dgraph Cloud

Running into CORS issues when my Blazor UI attempts to perform a simple query against my Dgraph Cloud instance. The OPTIONS preflight is sent and includes an Access-Control-Allow-Headers header in the response. However, this list does not contain the User-Agent header, which ultimately causes the preflight to fail and the browser blocks the GET from being sent.

As the Content-Type header is not one of text/plain, multipart/form-data, or application/x-www-form-urlencoded, GraphQL requests are not simple request. Thus, even GET requests will generate preflight requests and must satisfy CORS restraints.

Surely I can’t be the first to run into this issue, but Google-fu is failing me and I’m at a loss for a solution. I could maybe try to strip the User-Agent header out, but that’s obviously very hacky and far from ideal. I also do not see a way to configure CORS at all from my Dgraph Cloud console. Any pointers on how to interact with Dgraph Cloud from a browser client would be greatly appreciated.

Screenshots below show both the browser’s CORS failure and Dgraph Cloud’s response to the OPTIONS preflight. Merged into a single image to bypass new user restrictions.

It’s also worth noting that the Access-Control-Allow-Methods header does not include GET. This will likely also cause issues even if the CORS policy is updated to allow the User-Agent header.

Mozilla docs on the safe headers that do not need to be included in Access-Control-Allow-Headers:

Note that User-Agent is not on this list, and thus must be explicitly included in the CORS preflight response.

I dug into this some more to understand why the Dgraph Cloud console works fine. It appears that the UI framework I’m using sets a custom User-Agent header (GraphQL.Client/4.0.1.0) while the framework used by Dgraph Cloud just sends the default browser User-Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0).

Screenshot 2021-12-09 082557

Please consider adding the User-Agent header to the CORS preflight responses. I was able to work around this by nuking the header within the HTTP client config, but there’s really no good reason for requiring that on your end. I’m sure many other folk are going to run into this and lose a significant amount of time debugging the issue.