Middleware for multi-tenancy?

Users
#1

From what I gather, there is currently no native way of enforcing a namespace / multi-tenancy aspect that’s required for any modern SaaS project.

Is there a way to introduce middleware into the Dgraph server that would allow us to wrap / constraint any query / mutation by assessing for example a JWT auth token and wrapping the incoming query with a

// jwt { name: "johndoe" }
q(func: has(namespace-johndoe)) {
  ... incoming query ...
}
#2

There’s a lot of discussion here on Discuss about Multi-tenancy and ACLs. There are planes for this.

See Possible timeline of implementing ACL's in Dgraph - #2 by mrjn

#3

That post is literally a year old… Any updates since then?
And what about my question, is there a way to manually introduce a middleware until the native ACL is ready?

#4

There is an internal paper with update on this, the only update I can pass is that it has already started some work on this. But there is no date, as there are many other issues to be worked on.

You can try this One JS example with Dgraph-js for beginners. Using graphQL instead of REST or create some kind of REST. There’s no other way as far I know.

#5

Hi, Michel.

I have no experience with docker, but I was wondering if a docker farm could do the job until then. Like, one docker for each customer database, each one listening on a different port, and having some logic on app login to redirect the connection for each user. This could be a fix for a while (on a small scenario?).

If that can be done, would you have any docs or good practical examples to share of how to do that?

Thanks!

#6

In theory, yes can be done. In practical, too way complex to deal and I don’t think has examples for this available anywhere. Cuz is unusual this way of thinking tenancy usage.

And we can not spend time on this to create an example, as there are plans already for ACLs.

But, instead of this, you could create a Graph Structure inside Dgraph to simulate DBs. Like graph branches. Each branch your code would consider as a Client DB. You’d sharing the same DB for all costumers.

A Graph DB is a blank slate and you can painting as you want.

#7

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