🎁

12 Days of Baddass Courses sale! Get instant access to the entire egghead library of courses and lessons for 58% off.

Runs out in:
15 : 05 : 55 : 49
1×
Become a member
to unlock all features
Autoplay

    Creating an access token and choosing a role for it

    Chris BiscardiChris Biscardi
    faunadbFaunaDB

    FaunaDB supports access keys with four sets of permissions, or roles. You need an access token to use a language driver like the Go driver to access FaunaDB. It is not exposed by default. The four roles are: Admin, Server, Server-ReadOnly, and Client. We'll go over what these roles are and how to choose one for your use case.

    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Discuss

    Discuss

    Transcript

    Transcript

    Instructor: Here we are in the FaunaDB console. If we go to our database page and go to security, we'll be able to create a new access key. We need a new key to access the database from any of our client drivers. Note that we get to choose the database, in this case testDemo. It's possible that there could be nested databases here, in which case we'd have another option.

    Then we have a choice from four roles. Admin is full privileges. You probably don't want this. The next two interesting ones are server and server-readOnly. Server allows us to do destructive operations to the database we've selected, while server-readOnly only allows us to read them. These are good for lambdas or other service-based programming environments.

    Finally, we have client. Client only allows us to read specially marked public data. For example, because I have a lambda where I need to insert documents, I chose the server role. If my lambda only made queries to read, I could use the readOnly role.

    We can give the key a keyname and assign it a priority. A priority is a number between 1 and 500 that allows us to specify how important this key is, compared to all of the other keys. This importance is used to judge the priority of scheduling resources for each key. Note that this applies to high levels of saturation. We'll save our key.

    We can see our key is secret right here. As the notice says, it won't be displayed again. We have to go save it in 1Password or other password management solution, like Vault. We can see the key name in the ID, the role of the key and the database it's associated with. We can also revoke our key, which we'll do now.

    Note that now we've revoked our key and we have no keys left. We'll need to create a new key if we wanted to use it in one of the other client drivers.