GraphQL is becoming popular and developers are constantly looking for frameworks that make it easy to set up a fast, secure and scalable GraphQL API. In this article, we will learn how to create a scalable and fast GraphQL API with authentication and fine-grained data-access control (authorization). As an example, we’ll build an API with register and login functionality. The API will be about users and confidential files so we’ll define advanced authorization rules that specify whether a logged-in user can access certain files.
By using FaunaDB’s native GraphQL and security layer, we receive all the necessary tools to set up such an API in minutes. FaunaDB has a free tier so you can easily follow along by creating an account at https://dashboard.fauna.com/. Since FaunaDB automatically provides the necessary indexes and translates each GraphQL query to one FaunaDB query, your API is also as fast as it can be (no n+1 problems!).
Setting up the API is simple: drop in a schema and we are ready to start. So let’s get started!
The use-case: users and confidential files
We need an example use-case that demonstrates how security and GraphQL API features can work together. In this example, there are users and files. Some files can be accessed by all users, and some are only meant to be accessed by managers. The following GraphQL schema will define our model:
type User { username: String! @unique role: UserRole! } enum UserRole { MANAGER EMPLOYEE } type File { content: String! confidential: Boolean! } input CreateUserInput { username: String! password: String! role: UserRole! } input LoginUserInput { username: String! password: String! } type Query { allFiles: [File!]! } type Mutation { createUser(input: CreateUserInput): User! @resolver(name: "create_user") loginUser(input: LoginUserInput): String! @resolver(name: "login_user") }When looking at the schema, you might notice that the createUser and loginUser Mutation fields have been annotated with a special directive named @resolver. This is a directive provided by the FaunaDB GraphQL API, which allows us to define a custom behavior for a given Query or Mutation field. Since we’ll be using FaunaDB’s built-in authentication mechanisms, we will need to define this logic in FaunaDB after we import the schema.
Importing the schema
First, let’s import the example schema into a new database. Log into the FaunaDB Cloud Console with your credentials. If you don’t have an account yet, you can sign up for free in a few seconds.
Once logged in, click the “New Database” button from the home page:
Choose a name for the new database, and click the “Save” button:
Next, we will import the GraphQL schema listed above into the database we just created. To do so, create a file named schema.gql containing the schema definition. Then, select the GRAPHQL tab from the left sidebar, click the “Import Schema” button, and select the newly-created file:
The import process creates all of the necessary database elements, including collections and indexes, for backing up all of the types defined in the schema. It automatically creates everything your GraphQL API needs to run efficiently.
You now have a fully functional GraphQL API which you can start testing out in the GraphQL playground. But we do not have data yet. More specifically, we would like to create some users to start testing our GraphQL API. However, since users will be part of our authentication, they are special: they have credentials and can be impersonated. Let’s see how we can create some users with secure credentials!
Custom resolvers for authentication
Remember the createUser and loginUser mutation fields that have been annotated with a special directive named @resolver. createUser is exactly what we need to start creating users, however the schema did not really define how a user needs to created; instead, it was tagged with a @resolver tag.
By tagging a specific mutation with a custom resolver such as @resolver(name: "create_user") we are informing FaunaDB that this mutation is not implemented yet but will be implemented by a User-defined function (UDF). Since our GraphQL schema does not know how to express this, the import process will only create a function template which we still have to fill in.
A UDF is a custom FaunaDB function, similar to a stored procedure, that enables users to define a tailor-made operation in Fauna’s Query Language (FQL). This function is then used as the resolver of the annotated field.
We will need a custom resolver since we will take advantage of the built-in authentication capabilities which can not be expressed in standard GraphQL. FaunaDB allows you to set a password on any database entity. This password can then be used to impersonate this database entity with the Login function which returns a token with certain permissions. The permissions that this token holds depend on the access rules that we will write.
Let’s continue to implement the UDF for the createUser field resolver so that we can create some test users. First, select the Shell tab from the left sidebar:
As explained before, a template UDF has already been created during the import process. When called, this template UDF prints an error message stating that it needs to be updated with a proper implementation. In order to update it with the intended behavior, we are going to use FQL’s Update function.
So, let’s copy the following FQL query into the web-based shell, and click the “Run Query” button:
Update(Function("create_user"), { "body": Query( Lambda(["input"], Create(Collection("User"), { data: { username: Select("username", Var("input")), role: Select("role", Var("input")), }, credentials: { password: Select("password", Var("input")) } }) ) ) });Your screen should look similar to:
The create_user UDF will be in charge of properly creating a User document along with a password value. The password is stored in the document within a special object named credentials that is encrypted and cannot be retrieved back by any FQL function. As a result, the password is securely saved in the database making it impossible to read from either the FQL or the GraphQL APIs. The password will be used later for authenticating a User through a dedicated FQL function named Login, as explained next.
Now, let’s add the proper implementation for the UDF backing up the loginUser field resolver through the following FQL query:
Update(Function("login_user"), { "body": Query( Lambda(["input"], Select( "secret", Login( Match(Index("unique_User_username"), Select("username", Var("input"))), { password: Select("password", Var("input")) } ) ) ) ) });Copy the query listed above and paste it into the shell’s command panel, and click the “Run Query” button:
The login_user UDF will attempt to authenticate a User with the given username and password credentials. As mentioned before, it does so via the Login function. The Login function verifies that the given password matches the one stored along with the User document being authenticated. Note that the password stored in the database is not output at any point during the login process. Finally, in case the credentials are valid, the login_user UDF returns an authorization token called a secret which can be used in subsequent requests for validating the User’s identity.
With the resolvers in place, we will continue with creating some sample data. This will let us try out our use case and help us better understand how the access rules are defined later on.
Creating sample data
First, we are going to create a manager user. Select the GraphQL tab from the left sidebar, copy the following mutation into the GraphQL Playground, and click the “Play” button:
mutation CreateManagerUser { createUser(input: { username: "bill.lumbergh" password: "123456" role: MANAGER }) { username role } }Your screen should look like this:
Next, let’s create an employee user by running the following mutation through the GraphQL Playground editor:
mutation CreateEmployeeUser { createUser(input: { username: "peter.gibbons" password: "abcdef" role: EMPLOYEE }) { username role } }You should see the following response:
Now, let’s create a confidential file by running the following mutation:
mutation CreateConfidentialFile { createFile(data: { content: "This is a confidential file!" confidential: true }) { content confidential } }As a response, you should get the following:
And lastly, create a public file with the following mutation:
mutation CreatePublicFile { createFile(data: { content: "This is a public file!" confidential: false }) { content confidential } }If successful, it should prompt the following response:
Now that all the sample data is in place, we need access rules since this article is about securing a GraphQL API. The access rules determine how the sample data we just created can be accessed, since by default a user can only access his own user entity. In this case, we are going to implement the following access rules:
- Allow employee users to read public files only.
- Allow manager users to read both public files and, only during weekdays, confidential files.
As you might have already noticed, these access rules are highly specific. We will see however that the ABAC system is powerful enough to express very complex rules without getting in the way of the design of your GraphQL API.
Such access rules are not part of the GraphQL specification so we will define the access rules in the Fauna Query Language (FQL), and then verify that they are working as expected by executing some queries from the GraphQL API.
But what is this “ABAC” system that we just mentioned? What does it stand for, and what can it do?
What is ABAC?
ABAC stands for Attribute-Based Access Control. As its name indicates, it’s an authorization model that establishes access policies based on attributes. In simple words, it means that you can write security rules that involve any of the attributes of your data. If our data contains users we could use the role, department, and clearance level to grant or refuse access to specific data. Or we could use the current time, day of the week, or location of the user to decide whether he can access a specific resource.
In essence, ABAC allows the definition of fine-grained access control policies based on environmental properties and your data. Now that we know what it can do, let’s define some access rules to give you concrete examples.
Defining the access rules
In FaunaDB, access rules are defined in the form of roles. A role consists of the following data:
- name — the name that identifies the role
- privileges — specific actions that can be executed on specific resources
- membership — specific identities that should have the specified privileges
Roles are created through the CreateRole FQL function, as shown in the following example snippet:
CreateRole({ name: "role_name", membership: [ // ... ], privileges: [ // ... ] })You can see two important concepts in this role; membership and privileges. Membership defines who receives the privileges of the role and privileges defines what these permissions are. Let’s write a simple example rule to start with: “Any user can read all files.”
Since the rule applies on all users, we would define the membership like this:
membership: { resource: Collection("User") }Simple right? We then continue to define the “Can read all files” privilege for all of these users.
privileges: [ { resource: Collection("File"), actions: { read: true } } ]The direct effect of this is that any token that you receive by logging in with a user via our loginUser GraphQL mutation can now access all files.
This is the simplest rule that we can write, but in our example we want to limit access to some confidential files. To do that, we can replace the {read: true} syntax with a function. Since we have defined that the resource of the privilege is the “File” collection, this function will take each file that would be accessed by a query as the first parameter. You can then write rules such as: “A user can only access a file if it is not confidential”. In FaunaDB’s FQL, such a function is written by using Query(Lambda(‘x’, … <logic that users Var(‘x’)>)).
Below is the privilege that would only provide read access to non-confidential files:
privileges: [ { resource: Collection("File"), actions: { // Read and establish rule based on action attribute read: Query( // Read and establish rule based on resource attribute Lambda("fileRef", Not(Select(["data", "confidential"], Get(Var("fileRef")))) ) ) } } ]This directly uses properties of the “File” resource we are trying to access. Since it’s just a function, we could also take into account environmental properties like the current time. For example, let’s write a rule that only allows access on weekdays.
privileges: [ { resource: Collection("File"), actions: { read: Query( Lambda("fileRef", Let( { dayOfWeek: DayOfWeek(Now()) }, And(GTE(Var("dayOfWeek"), 1), LTE(Var("dayOfWeek"), 5)) ) ) ) } } ]As mentioned in our rules, confidential files should only be accessible by managers. Managers are also users, so we need a rule that applies to a specific segment of our collection of users. Luckily, we can also define the membership as a function; for example, the following Lambda only considers users who have the MANAGER role to be part of the role membership.
membership: { resource: Collection("User"), predicate: Query( // Read and establish rule based on user attribute Lambda("userRef", Equals(Select(["data", "role"], Get(Var("userRef"))), "MANAGER") ) ) }In sum, FaunaDB roles are very flexible entities that allow defining access rules based on all of the system elements’ attributes, with different levels of granularity. The place where the rules are defined — privileges or membership — determines their granularity and the attributes that are available, and will differ with each particular use case.
Now that we have covered the basics of how roles work, let’s continue by creating the access rules for our example use case!
In order to keep things neat and tidy, we’re going to create two roles: one for each of the access rules. This will allow us to extend the roles with further rules in an organized way if required later. Nonetheless, be aware that all of the rules could also have been defined together within just one role if needed.
Let’s implement the first rule:
“Allow employee users to read public files only.”
In order to create a role meeting these conditions, we are going to use the following query:
CreateRole({ name: "employee_role", membership: { resource: Collection("User"), predicate: Query( Lambda("userRef", // User attribute based rule: // It grants access only if the User has EMPLOYEE role. // If so, further rules specified in the privileges // section are applied next. Equals(Select(["data", "role"], Get(Var("userRef"))), "EMPLOYEE") ) ) }, privileges: [ { // Note: 'allFiles' Index is used to retrieve the // documents from the File collection. Therefore, // read access to the Index is required here as well. resource: Index("allFiles"), actions: { read: true } }, { resource: Collection("File"), actions: { // Action attribute based rule: // It grants read access to the File collection. read: Query( Lambda("fileRef", Let( { file: Get(Var("fileRef")), }, // Resource attribute based rule: // It grants access to public files only. Not(Select(["data", "confidential"], Var("file"))) ) ) ) } } ] })Select the Shell tab from the left sidebar, copy the above query into the command panel, and click the “Run Query” button:
Next, let’s implement the second access rule:
“Allow manager users to read both public files and, only during weekdays, confidential files.”
In this case, we are going to use the following query:
CreateRole({ name: "manager_role", membership: { resource: Collection("User"), predicate: Query( Lambda("userRef", // User attribute based rule: // It grants access only if the User has MANAGER role. // If so, further rules specified in the privileges // section are applied next. Equals(Select(["data", "role"], Get(Var("userRef"))), "MANAGER") ) ) }, privileges: [ { // Note: 'allFiles' Index is used to retrieve // documents from the File collection. Therefore, // read access to the Index is required here as well. resource: Index("allFiles"), actions: { read: true } }, { resource: Collection("File"), actions: { // Action attribute based rule: // It grants read access to the File collection. read: Query( Lambda("fileRef", Let( { file: Get(Var("fileRef")), dayOfWeek: DayOfWeek(Now()) }, Or( // Resource attribute based rule: // It grants access to public files. Not(Select(["data", "confidential"], Var("file"))), // Resource and environmental attribute based rule: // It grants access to confidential files only on weekdays. And( Select(["data", "confidential"], Var("file")), And(GTE(Var("dayOfWeek"), 1), LTE(Var("dayOfWeek"), 5)) ) ) ) ) ) } } ] })Copy the query into the command panel, and click the “Run Query” button:
At this point, we have created all of the necessary elements for implementing and trying out our example use case! Let’s continue with verifying that the access rules we just created are working as expected…
Putting everything in action
Let’s start by checking the first rule:
“Allow employee users to read public files only.”
The first thing we need to do is log in as an employee user so that we can verify which files can be read on its behalf. In order to do so, execute the following mutation from the GraphQL Playground console:
mutation LoginEmployeeUser { loginUser(input: { username: "peter.gibbons" password: "abcdef" }) }As a response, you should get a secret access token. The secret represents that the user has been authenticated successfully:
At this point, it’s important to remember that the access rules we defined earlier are not directly associated with the secret that is generated as a result of the login process. Unlike other authorization models, the secret token itself does not contain any authorization information on its own, but it’s just an authentication representation of a given document.
As explained before, access rules are stored in roles, and roles are associated with documents through their membership configuration. After authentication, the secret token can be used in subsequent requests to prove the caller’s identity and determine which roles are associated with it. This means that access rules are effectively verified in every subsequent request and not only during authentication. This model enables us to modify access rules dynamically without requiring users to authenticate again.
Now, we will use the secret issued in the previous step to validate the identity of the caller in our next query. In order to do so, we need to include the secret as a Bearer Token as part of the request. To achieve this, we have to modify the Authorization header value set by the GraphQL Playground. Since we don’t want to miss the admin secret that is being used as default, we’re going to do this in a new tab.
Click the plus (+) button to create a new tab, and select the HTTP HEADERS panel on the bottom left corner of the GraphQL Playground editor. Then, modify the value of the Authorization header to include the secret obtained earlier, as shown in the following example. Make sure to change the scheme value from Basic to Bearer as well:
{ "authorization": "Bearer fnEDdByZ5JACFANyg5uLcAISAtUY6TKlIIb2JnZhkjU-SWEaino" }With the secret properly set in the request, let’s try to read all of the files on behalf of the employee user. Run the following query from the GraphQL Playground:
query ReadFiles { allFiles { data { content confidential } } }In the response, you should see the public file only:
Since the role we defined for employee users does not allow them to read confidential files, they have been correctly filtered out from the response!
Let’s move on now to verifying our second rule:
“Allow manager users to read both public files and, only during weekdays, confidential files.”
This time, we are going to log in as the employee user. Since the login mutation requires an admin secret token, we have to go back first to the original tab containing the default authorization configuration. Once there, run the following query:
mutation LoginManagerUser { loginUser(input: { username: "bill.lumbergh" password: "123456" }) }You should get a new secret as a response:
Copy the secret, create a new tab, and modify the Authorization header to include the secret as a Bearer Token as we did before. Then, run the following query in order to read all of the files on behalf of the manager user:
query ReadFiles { allFiles { data { content confidential } } }As long as you’re running this query on a weekday (if not, feel free to update this rule to include weekends), you should be getting both the public and the confidential file in the response:
And, finally, we have verified that all of the access rules are working successfully from the GraphQL API!
Conclusion
In this post, we have learned how a comprehensive authorization model can be implemented on top of the FaunaDB GraphQL API using FaunaDB’s built-in ABAC features. We have also reviewed ABAC’s distinctive capabilities, which allow defining complex access rules based on the attributes of each system component.
While access rules can only be defined through the FQL API at the moment, they are effectively verified for every request executed against the FaunaDB GraphQL API. Providing support for specifying access rules as part of the GraphQL schema definition is already planned for the future.
In short, FaunaDB provides a powerful mechanism for defining complex access rules on top of the GraphQL API covering most common use cases without the need for third-party services.
The post Instant GraphQL Backend with Fine-grained Security Using FaunaDB appeared first on CSS-Tricks.
Roll Your Own Comments With Gatsby and FaunaDB
If you haven’t used Gatsby before have a read about why it’s fast in every way that matters, and if you haven’t used FaunaDB before you’re in for a treat. If you’re looking to make your static sites full blown Jamstack applications this is the back end solution for you!
This tutorial will only focus on the operations you need to use FaunaDB to power a comment system for a Gatsby blog. The app comes complete with inputs fields that allow users to comment on your posts and an admin area for you to approve or delete comments before they appear on each post. Authentication is provided by Netlify’s Identity widget and it’s all sewn together using Netlify serverless functions and an Apollo/GraphQL API that pushes data up to a FaunaDB database collection.
I chose FaunaDB for the database for a number of reasons. Firstly there’s a very generous free tier! perfect for those small projects that need a back end, there’s native support for GraphQL queries and it has some really powerful indexing features!
…and to quote the creators;
You can see the finished comments app here.
Get Started
To get started clone the repo at https://github.com/PaulieScanlon/fauna-gatsby-comments
or:
Then install all the dependencies:
Also
cdin tofunctions/apollo-graphqland install the dependencies for the Netlify function:This is a separate package and has its own dependencies, you’ll be using this later.
We also need to install the Netlify CLI as you’ll also use this later:
Now lets add three new files that aren’t part of the repo.
At the root of your project create a
.env.env.developmentand.env.productionAdd the following to
.env:Add the following to
.env.development:Add the following to
.env.production:You’ll come back to these later but in case you’re wondering
GATSBY_FAUNA_DBis the FaunaDB secret key for your databaseGATSBY_FAUNA_COLLECTIONis the FaunaDB collection nameGATSBY_SHOW_SIGN_UPis used to hide the Sign up button when the site is in productionGATSBY_ADMIN_IDis a user id that Netlify Identity will generate for youIf you’re the curious type you can get a taster of the app by running
gatsby developoryarn developand then navigate tohttp://localhost:8000in your browser.FaunaDB
So Let’s get cracking, but before we write any operations head over to https://fauna.com/ and sign up!
Database and Collection
fauna-gatsby-commentsdemo-blog-commentsServer Key
Now you’ll need to to set up a server key. Go to SECURITY
fauna-gatsby-commentsfor exampledemo-blog-server-keyEnvironment Variables Pt. 1
Copy the server key and add it to
GATSBY_FAUNA_DBin.env.development,.env.productionand.env.You’ll also need to add the name of the collection to
GATSBY_FAUNA_COLLECTIONin.env.development,.env.productionand.env.Adding these values to
.envare just so you can test your development FaunaDB operations, which you’ll do next.Let’s start by creating a comment so head back to
boop.js:The breakdown of this function is as follows;
qis the instance offaunadb.queryCreateis the FaunaDB method to create an entry within a collectionCollectionis area in the database to store the data. It takes the name of the collection as the first argument and a data object as the second.The second argument is the shape of the data you need to drive the applications comment system.
For now you’re going to hard-code
slug,nameandcommentbut in the final app these values are captured by the input form on the posts page and passed in via argsThe breakdown for the shape is as follows;
isApprovedis the status of the comment and by default it’s false until we approve it in the Admin pageslugis the path to the post where the comment was writtendateis the time stamp the comment was writtennameis the name the user entered in the comments fromcommentis the comment the user entered in the comments formWhen you (or a user) creates a comment you’re not really interested in dealing with the response because as far as the user is concerned all they’ll see is either a success or error message.
After a user has posted a comment it will go in to your Admin queue until you approve it but if you did want to return something you could surface this in the UI by returning something from the
createCommentfunction.Create a comment
If you’ve hard coded a
slug,nameandcommentyou can now run the following in your CLIIf everything worked correctly you should see a log in your terminal of the new comment.
If you head over to COLLECTIONS in FaunaDB you should see your new entry in the collection.
You’ll need to create a few more comments while in development so change the hard-coded values for
nameandcommentand run the following again.Do this a few times so you end up with at least three new comments stored in the database, you’ll use these in a moment.
Delete comment by id
Now that you can create comments you’ll also need to be able to delete a comment.
By adding the
commentIdof one of the comments you created above you can delete it from the database. ThecommentIdis theidin theref.@refobjectAgain you’re not really concerned with the return value here but if you wanted to surface this in the UI you could do so by returning something from the
deleteCommentByIdfunction.The breakdown of this function is as follows
clientis the FaunaDB client instancequeryis a method to get data from FaunaDBqis the instance offaunadb.queryDeleteis the FaunaDB delete method to delete entries from a collectionRefis the unique FaunaDB ref used to identify the entryCollectionis area in the database where the data is storedIf you’ve hard coded a
commentIdyou can now run the following in your CLI:If you head back over to COLLECTIONS in FaunaDB you should see that entry no longer exists in collection
Indexes
Next you’re going to create an INDEX in FaunaDB.
An INDEX allows you to query the database with a specific term and define a specific data shape to return.
When working with GraphQL and / or TypeScript this is really powerful because you can use FaunaDB indexes to return only the data you need and in a predictable shape. This makes data typing responses in GraphQL and / TypeScript a dream… I’ve worked on a number of applications that just return a massive object of useless values which will inevitably cause bugs in your app. blurg!
get-all-commentsAs mentioned above when you query the database using this index you can tell FaunaDB which parts of the entry you want to return.
You can do this by adding “values” but be careful to enter the values exactly as they appear below because (on the FaunaDB free tier) you can’t amend these after you’ve created them so if there’s a mistake you’ll have to delete the index and start again… bummer!
The values you need to add are as follows:
refdata.isApproveddata.slugdata.datedata.namedata.commentAfter you’ve added all the values you can click SAVE.
Get all comments
The breakdown of this function is as follows
clientis the FaunaDB client instancequeryis a method to get data from FaunaDBqis the instance offaunadb.queryPaginatepaginates the responsesMatchreturns matched resultsIndexis the name of the Index you just createdThe shape of the returned result here is an array of the same shape you defined in the Index “values”
If you run the following you should see the list of all the comments you created earlier:
Get comments by slug
You’re going to take a similar approach as above but this time create a new Index that allows you to query FaunaDB in a different way. The key difference here is that when you
get-comments-by-slugyou’ll need to tell FaunaDB about this specific term and you can do this by addingdata.slugto the Terms field.get-comments-by-slugdata.slugin the terms fieldThe values you need to add are as follows:
refdata.isApproveddata.slugdata.datedata.namedata.commentAfter you’ve added all the values you can click SAVE.
The breakdown of this function is as follows:
clientis the FaunaDB client instancequeryis a method to get data from FaunaDBqis the instance offaunadb.queryPaginatepaginates the responsesMatchreturns matched resultsIndexis the name of the Index you just createdThe shape of the returned result here is an array of the same shape you defined in the Index “values” you can create this shape in the same way you did above and be sure to add a value for terms. Again be careful to enter these with care.
If you run the following you should see the list of all the comments you created earlier but for a specific
slug:Approve comment by id
When you create a comment you manually set the
isApprovedvalue to false. This prevents the comment from being shown in the app until you approve it.You’ll now need to create a function to do this but you’ll need to hard-code a
commentId. Use acommentIdfrom one of the comments you created earlier:The breakdown of this function is as follows:
clientis the FaunaDB client instancequeryis a method to get data from FaunaDBqis the instance offaunadb.queryUpdateis the FaundaDB method up update an entryRefis the unique FaunaDB ref used to identify the entryCollectionis area in the database where the data is storedIf you’ve hard coded a
commentIdyou can now run the following in your CLI:If you run the
getCommentsBySlugagain you should now see theisApprovedstatus of the entry you hard-coded thecommentIdfor will have changed totrue.These are all the operations required to manage the data from the app.
In the repo if you have a look at
apollo-graphql.jswhich can be found infunctions/apollo-graphqlyou’ll see the all of the above operations. As mentioned before the hard-coded values are replaced byargs, these are the values passed in from various parts of the app.Netlify
Assuming you’ve completed the Netlify sign up process or already have an account with Netlify you can now push the demo app to your GitHub account.
To do this you’ll need to have initialize git locally, added a remote and have pushed the demo repo upstream before proceeding.
You should now be able to link the repo up to Netlify’s Continuous Deployment.
If you click the “New site from Git” button on the Netlify dashboard you can authorize access to your GitHub account and select the
gatsby-fauna-commentsrepo to enable Netlify’s Continuous Deployment. You’ll need to have deployed at least once so that we have a pubic URL of your app.The URL will look something like this
https://ecstatic-lewin-b1bd17.netlify.appbut feel free to rename it and make a note of the URL as you’ll need it for the Netlify Identity step mentioned shortly.Environment Variables Pt. 2
In a previous step you added the FaunaDB database secret key and collection name to your
.envfiles(s). You’ll also need to add the same to Netlify’s Environment variables.Proceed to add the following:
While you’re here you’ll also need to amend the Sensitive variable policy, select Deploy without restrictions
Netlify Identity Widget
I mentioned before that when a comment is created the
isApprovedvalue is set tofalse, this prevents comments from appearing on blog posts until you (the admin) have approved them. In order to become admin you’ll need to create an identity.You can achieve this by using the Netlify Identity Widget.
If you’ve completed the Continuous Deployment step above you can navigate to the Identity page from the Netlify navigation.
You wont see any users in here just yet so lets use the app to connect the dots, but before you do that make sure you click Enable Identity
Before you continue I just want to point out you’ll be using
netlify devinstead ofgatsby developoryarn developfrom now on. This is because you’ll be using some “special” Netlify methods in the app and staring the server usingnetlify devis required to spin up various processes you’ll be using.netlify devhttp://localhost:8888/admin/You will also need to point the Netlify Identity widget at your newly deployed app URL. This was the URL I mentioned you’ll need to make a note of earlier, if you’ve not renamed your app it’ll look something like this
https://ecstatic-lewin-b1bd17.netlify.app/There will be a prompt in the pop up window to Set site’s URL.You can now complete the necessary sign up steps.
After sign up you’ll get an email asking you to confirm you identity and once that’s completed refresh the Identity page in Netlify and you should see yourself as a user.
It’s now login time, but before you do this find
Identity.jsinsrc/componentsand temporarily un-comment theconsole.log()on line 14. This will log the Netlify Identity user object to the console.netlify devIf this all works you should be able to see a console log for
netlifyIdentity.currentUser:find theidkey and copy the value.Set this as the value for
GATSBY_ADMIN_ID =in both.env.productionand.env.developmentYou can now safely remove the
console.log()on line 14 inIdentity.jsor just comment it out again.…and finally
netlify devNow you should be able to login as “Admin”… hooray!
Navigate to
http://localhost:8888/admin/and Login.It’s important to note here you’ll be using
localhost:8888for development now and NOTlocalhost:8000which is more common with Gatsby developmentBefore you test this in the deployed environment make sure you go back to Netlify’s Environment variables and add your Netlify Identity user
idto the Environment variables!Proceed to add the following:
If you have a play around with the app and enter a few comments on each of the posts then navigate back to Admin page you can choose to either approve or delete the comments.
Naturally only approved comments will be displayed on any given post and deleted ones are gone forever.
If you’ve used this tutorial for your project I’d love to hear from you at @pauliescanlon.
By Paulie Scanlon (@pauliescanlon), Front End React UI Developer / UX Engineer: After all is said and done, structure + order = fun.
Visit Paulie’s Blog at: www.paulie.dev
The post Roll Your Own Comments With Gatsby and FaunaDB appeared first on CSS-Tricks.
CSS-Tricks