Client direct connection with fine-grained permissions

[troutshorty]

Hi,
I’m just getting started with Fauna. I have a purely public web application that is currently fetching some data from a Fauna database via Netlify serverless function calls. I’m thinking I could improve performance by having the client code access the Fauna database directly (the function calls take only a few hundredths of a second, but fetching via Netlify is taking about a half-second).

I think I can do this by creating a custom role ‘anyone’, with fine-grained execute permissions on a handful of Fauna functions (which only return data), then just make the secret for the ‘anyone’ role stored on the server and loaded into memory on the client side so it could get an instance of the faunadb client.

I suppose that the secret for the ‘anyone’ role would be exposed, say in the web dev tools debugger, but since it would have such limited access, I don’t see a security risk. I don’t see a need for keys or tokens in this case. Does that make sense – or am I missing something?

Thanks!

[ptpaterson]

Hi @troutshorty, welcome to the forums!

This makes total sense. Depending on what you need from the database, you can simply provide the permissions in the anyone Role to read the necessary Collections, Indexes, and Functions.

In our examples, we make use of public keys which only have access to certain things:

• read public Documents
• call the login or register Functions
• etc.

This sample app is designed to work without a backend. While it does introduces user authentication, it also has a public Role for keys that are shared directly in the app for everyone.

Encapsulating your logic in UDFs is also highly recommended. You gain a couple of benefits with this pattern: more control over the permissions, and easier migrations in the future. In this case, the anyone key is given ONLY permissions to call specific UDFs, and the UDFs are given heightened privileges for what they need to do. Maybe you want to add some write-logic to your app, such as writing to a log every time a UDF is called – that’s just a matter of updating your UDF in place and there is no disruption to your app. If the shape of your data needs to change, you can update UDFs that provide calculated fields, or even temporarily polyfill your data while you make permanent updates to all of your records.

[troutshorty]

Thanks @ptpaterson! I really appreciate your feedback on this. I’m really enjoing learning about FQL and the documentation is great. I’ll take a close look at the sample app you linked!