Ratel with long URLs


(Alex Miłowski) #1

It looks as though the Ratel UI doesn’t work with long URLs. I was accessing the server via the k8s API. For example:

http://localhost:8080/api/v1/namespaces/dgraph/services/dgraph-server:8080/proxy/

using kubectl proxy.

Also, it would be great if the UI and/or server supported CORS.


(Daniel Mai) #2

Long URLs should work. I’ve used a URL like this in Ratel before: http://localhost:8080/api/v1/proxy/namespaces/default/services/dgraph-server-0-public:8080/

What’s the use case for CORS? The Dgraph Server URL in Ratel can be any publicly accessible endpoint.


(Alex Miłowski) #3

Without CORS, I can’t run digraph-ratel locally and connect to a server elsewhere. The browser will deny access.

WRT long URLs, it doesn’t seem to work. When I try to send requests, it sends them to the wrong location (looking in the console).


(Daniel Mai) #4

Is there something different between my setup and yours? I can connect to other Dgraphs outside of a local Ratel served on localhost.


(Paul Korzhyk) #5

What do you see in browser at the following link? http://localhost:8080/api/v1/namespaces/dgraph/services/dgraph-server:8080/proxy/health?debug=true

Dgraph server adds CORS headers and responds to pre-flight. We rely on those features at tour.dgraph.io for example. What else do you need for your use case?


(Alex Miłowski) #6

Against v1.0.8 running in k8s (GKE) via the kubectl proxy:

curl -v -H "Origin: http://localhost:8000" -H "Referer: http://locahost:8080/" "http://localhost:8080/api/v1/namespaces/dgraph/services/dgraph-server:8080/proxy/health?debug=true"

> GET /api/v1/namespaces/dgraph/services/dgraph-server:8080/proxy/health?debug=true HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.54.0
> Accept: */*
> Origin: http://localhost:8000
> Referer: http://locahost:8080/
>
< HTTP/1.1 200 OK
< Audit-Id: 9e8da082-e575-4d61-bc21-6615bdadbb8e
< Content-Length: 2
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 07 Sep 2018 16:35:19 GMT
<

No Access-Control-Allow-Origin header is returned

From the browser (Safari) console:

[Error] Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin.
[Error] Failed to load resource: Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin. (keywords, line 0)
[Error] Fetch API cannot load http://localhost:8080/api/v1/namespaces/dgraph/services/dgraph-server:8080/proxy/ui/keywords?debug=true. Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin.
[Error] Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin.
[Error] Failed to load resource: Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin. (health, line 0)
[Error] Fetch API cannot load http://localhost:8080/api/v1/namespaces/dgraph/services/dgraph-server:8080/proxy/health?debug=true. Origin http://localhost:8000 is not allowed by Access-Control-Allow-Origin.

There are no CORS headers returned.


(Alex Miłowski) #7

Ah ha! The K8S proxy is dropping the headers. If you forward the port from the server pod it returns the CORS headers.

This is a K8S + DGraph issue.


(Paul Korzhyk) #8

I’m not sure you can blame dgraph here - it’s doing its job by sending the headers. we can’t ban middlemen from stripping them, in most cases we don’t even know if middlemen are there :slight_smile:

I’m not very familiar with k8s, are you using one of our official dgraph-<somehing>.yaml config files or running your own config with extra proxy settings?


(Alex Miłowski) #9

Well… using custom headers is generally a bad idea for web protocols.

Since Dgraph has no security controls, you can’t expose a public service. You have to proxy ingresses for connecting to the database.


(system) #10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.