At the documentation on dgraph administration (https://dgraph.io/docs/deploy/dgraph-administration/) it says that to access admin functions the IP from where these functions are accessed must be whitelisted - and this makes sense.
I cannot find anything that mentions updating a schema to be a part of the admin functions.
However, when I add my clients IP to the whitelist I can update the schema.
I was wondering if this happened by accident? or if the documentation is lagging behind the development?
I would argue that updating a schema is different from administrating the database, and therefore it should be possible to update the schema, without the need for white listening.
I would argue against you on this one, sorry. I don’t want everyone in the world to have access to delete my entire schema or add/remove any types and properties as they wanted to.
Thanks for your inputs. Do you have other examples that create this impression? It would be help us understand the nature of gaps in the documentation and address it.
You can set the whitelist IP option in Alpha (--whitelist) to set the IPs allowed for these operations. By default, it’s set to localhost (127.0.0.1), and you can set it to a CIDR range for private IPs or open it up to all IPs (0.0.0.0/0).
@vvbalaji I said that not in spite but just as a matter of fact. The rate of development of Dgraph will always lead to docs following behind. It is the nature of the beast. I have submitted some PR for docs (mainly to Dgraph GraphQL docs so far). If I find any issues I try to help bring them to attention. New features sometimes cannot be documented simultaneously because they are not finalized in development. If I want to use the master build then I take with that the understanding of some things just not yet documented.
Another example is Slash query cost can be found in the header in 3rd party clients and not in the response bodies as is in API Explorer. The fact that it was not yet documented was not because of poor documentation team but most likely rather to an oversight. How do you know what to document sometimes until a users asks about it and it is realized it is not documented anywhere.
This open forum with the devs is amazing! It helps get issues handled where documentation is unclear or otherwise lacking.
I had this PR which updated the Dgraph administration docs with the content of discuss post @dmai has pointed to. But, it seems recently docs have been broken with this PR. The PR diff shows that the previous content is not exactly put in as the new content. What I see in the docs at present, is the version before I had merged my PR.
@vvbalaji there can be other changes too which may have been lost.
In my case the dGraph endpoint is not public to the world, and I would like to update the schema from my clients. The IP address of the clients who have access to the endpoint varies depending on the environment they are running. Eg. my developer, testing, staging, and production environment (which there is many of9 will all have different IP addresses for the client accessing the dGraph endpoint. Maintaining and updating a list of possible IP addresses for each of the environments and for each of the production environments could be a source of problems. And that is why I argue that managing the schema and mutating data is of the same “kind” and should not be protected by a whitelisting
For administration of the endpoint as drop, backup/export, security, updating etc. it makes sense to have a whitelist, because these operations are more about the database itself - and not the data managed by the database.
Anyway, I’m sure that the great people at dGraph has made this design change after a lengthy discussion, and are considering other use-cases than mine.
Thanks, since I’m using Kubernetes to host my dGraph and my services who access the dGraph endpoints, I’ll get the necessary IP values from Kubernetes - thanks - this was helpful.
