Using scoped keys for multi-level nested databases

Is there any way to use the scoped keys method to access multi-layered child databases? I have seen and tested the posted solutions and documentation on Keys - Scoped Keys | Fauna Documentation, but this seems restricted to only the child database but no further layer.

I am using the JS driver for my project and I can create the child db client easily with

var child_secret = `${db_secret}:${child_db_name}:${access_role}`;
var childClient = new faunadb.Client({secret: child_secret});

and begin using childClient for my queries, but it seems that to go another layer further would take quick a bit of work and need a secrete system in place.

Hi Michael,

Thanks for joining our Fauna forums!

When using scoped keys, you’re able to get access to any of the child databases for the database that generated the key. But it’s important to keep in mind how those child databases are stored; like anything else in Fauna, they have a reference stored in the parent database. If you can’t map the name of the child database within the data inside the parent, the authentication won’t work.

So scoped keys will work with any child database, but not with any grandchild database. You would need to create a new key for the child in order to access grandchildren.

Please let me know if this solves your question or if you have any follow up questions.

Thanks,
Cory

1 Like

Your child database name can use the slash (/) separator, like a folder separator. For example, if you have a key with the “admin” role to access database A, and A has the child database B, and B has the child database C, you can use a scoped key to access C with <admin_secret>:B/C:admin

I’ve made a note to add this point to the documentation.

Note that you cannot execute queries that write to child databases. If you are connected to A, you cannot write to B or C. You’d need to use a scoped key to connect to B to perform writes in B, and another scoped key to connect to C to perform writes in C.

3 Likes

@ewan Thanks for your solution, just for the purpose of reading the nested databases, your solution is what I am looking for for now! Although eventually I foresee needing to do writes to the child/nested databases, which seems like we still need to access the child like @Cory_Fauna suggested, will definitely think a bit further on how we want to manage this as the chance comes.

From a quick test, i was able to verify that creating a new js
<admin_secret>:B/C:admin
has worked for me. See my code below

var faunadb = require("faunadb");
var fquery = faunadb.query;

var grand_child_secret = `${db_secret}:${child_db_name}/${grand_child_db_name}:${access_role}`;
var grandChildClient = new faunadb.Client({
		secret: grand_child_secret
	})
var result = await grandChildClient.query(
    fquery.CreateCollection({
        name: "grand_child_db_collection"
    })
)
// 

Although, interestingly it seems my JS client object i created for the child (and as well grand child database) from the secret method above was still able to write to my child/grandchild databases (I was able to create grandchild DB collections, and grand-grandchild DB). Not sure if this is intended or an undocumented behaviour.

Perhaps something that would be convenient in the future is having the option to be able to control the nested db access behaviour. I can see the cases which it’s useful to block write access from the higher level keys, but i can also imagine many cases which should allow the higher level key to inherit full access to the below nested keys.

Thanks guys for your help!

1 Like

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