I posted my graphql endpoint here in the forum to get some assistance and I am literally watching data be erased! 
Is there anyway to see who is connected with any Dgraph tools?
Is there any kind of data history within Dgraph outside of backups and export/import?
Oh, and it would be nice if there was an easy way to Poor Man Secure the main :8080 port that can bypass all graphql auth rules other than putting it behind another service.
I am going to just make a hard data dump to prevent any more data leaks. This is sickening!
Hi @amaster507, I am sorry to hear that some of your data got erased. It seems like you posted a link for the public url of your dgraph server which someone misused. I’d recommend against doing that in the future as all the topics in Users are available for anyone to view. Did your schema have any Auth rules in it?
No there isn’t anyway to do that right now.
We are working on Point in time recovery and that should help you with something like this soon. For now regular incremental backups are the way to go to recover from something like this.
Sure, we can look into doing that. If we applied the poor mans auth to the GraphQL endpoint then all requests would require the token to make any queries or mutations. Would that work for you?
That would cover about half of the whole. Here is the scenario. I have to open port 8080 to expose the graphql endpoint. There needs to be some built in security service besides enterprise ACL to block ANYONE from just firing up ratel and pointing it at my :8080/ endpoint and having full access bypassing the GraphQL endpoint entirely. This needs to be built in and not require setting up another layer or service.
What I have to do in the meantime before I can import any more data and actually get back to work is to figure out AWS API Gateway and put it in front of my EC2 port 8080 to only allow access to the :8080/graphql endpoint.
I understand that I am responsible for securing the graphql endpoint with auth rules, but there is no way to ONLY expose the graphql endpoint without also exposing the :8080/ endpoint natively.
Sorry to hear about this. 
Actually, there is. You can use a reverse proxy. I use Traefik, and I’m able to expose a Dgraph cluster with no security at all (no ALC, no Poor man’s ACL and etc) and it is safe from trolls.
See, this above is my ingress setup. I have exposed 8080/, 8080/query, 8080/health, 8080/admin - I can remove any of than any time. So, no one is able to dig around and find any path and mess up with it.
I have also tested other ways to mess up with it. But it is not possible with reverse proxy. Cuz I don’t expose /Alter, /commit, /mutation, or any other. For me, reverse proxies are the holy grail.
I’ve come up with an interesting setup myself here Cloudflare Workers + Access + Argo Tunnel - Workers - Cloudflare Community I have a DigitalOcean Droplet running Dgraph (for now… will use Kubernetes later) and Cloudflare Argo Tunnel running on my Dgraph Alpha Port (8080). I’ve got Cloudflare Access in front of my Load Balancer that makes the queries to Dgraph, so that only my Workers can send requests to it 
right, that protects the /graphql endpoint but not the / which without additional setup steps and another service as others are describing above then anyone can literally just fire up ratel locally and point at it, or CURL post to it.
Hopefully this is easier than trying to figure out AWS API Gateway. AWS has very good ways at making anything complicated.
@amaster507 are you Slash GraphQL? If so then we have access logs and can dig into who accessed the instances.
We do have support for authorization rules in GraphQL which help you with these scenarios. See https://graphql.dgraph.io/authorization/ for more details. You’ll still have to block all other endpoints like /query and /mutate. These are disabled by default if you are using Slash GraphQL. Maybe we could also support starting Dgraph in GraphQL only mode which disables these endpoints by default so that the user doesn’t have to do this.
And to answer this question, I do have some, still not complete, but the predicates that I found dropped I believed to have been dropped by using a dgraph mutation and not the graphql endpoints because they were just deleted on one side and the graphql endpoint would (should) have deleted the predicates from both sides with the hasInverse directives.
I want to use Slash and I have access to it, but there is no good way yet to live load or bulk load my data into it. So I am working on getting setup on our own Dgraph ec2 instance to get back into UI development until Slash can import data.
I think that would be a good solution as well. This would mean that no one not even myself would have access to using ratel console which I find helpful to management tasks to do some things that are not yet supported by the graphql endpoint. So Pro/Con but at least it solves the security whole.
Another solution here could be that we apply poor man’s Auth to query and mutate endpoint as well. It’s already applied to Admin operations but can also be used to secure the /query endpoint.
I hope Slash GraphQL will eventually add domain restrictions, like Firebase Authorized Domains*, as well.
The url can be public, but the endpoint will work only if called from certain domains.
I would very much like that please.
Firebase Authorized Domains*:
I believe that is also possible with traefic. I can see both sides of the coin: 1) end users want all in one tool amd dont want to go figure out how to secure endpoints with another tool. 2) devs see that it is possible to secure endpoints with another tool so they focus their attention on what only dgraph does/does not do.
I belive Firebase Authorized Domains only work at a CORS level, ie, it prevents you from accessing that firebase db from a browser on another origin. It will not protect your firebase db from a curl / api client which just sets the origin header.
