Setting up the API is simple: drop in a schema and we are ready to start. So let\u2019s get started! <\/p>\n\n\n\n\n\n\n
The use-case: users and confidential files<\/h1>\n\n\n
We need an example use-case that demonstrates how security and GraphQL API features can work together. In this example, there are users<\/strong> and files.<\/strong> 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:<\/p>\n\n\n\n When looking at the schema, you might notice that the First, let\u2019s import the example schema into a new database. Log into the FaunaDB Cloud Console<\/a> with your credentials. If you don\u2019t have an account yet, you can sign up for free in a few seconds.<\/p>\n\n\n\n Once logged in, click the “New Database” button from the home page:<\/p>\n\n\n\n Choose a name for the new database, and click the “Save” button: <\/p>\n\n\n\n Next, we will import the GraphQL schema listed above into the database we just created. To do so, create a file named 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. <\/p>\n\n\n\n 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\u2019s see how we can create some users with secure credentials!<\/p>\n\n\n Remember the By tagging a specific mutation with a custom resolver such as A UDF is a custom FaunaDB function, similar to a stored procedure<\/em>, that enables users to define a tailor-made operation in Fauna\u2019s Query Language (FQL<\/a>). This function is then used as the resolver of the annotated field. <\/p>\n\n\n\n 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 Let\u2019s continue to implement the UDF for the 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<\/a> function.<\/p>\n\n\n\n So, let\u2019s copy the following FQL query into the web-based shell, and click the “Run Query” button:<\/p>\n\n\n\n Your screen should look similar to:<\/p>\n\n\n\n The Now, let\u2019s add the proper implementation for the UDF backing up the Copy the query listed above and paste it into the shell\u2019s command panel, and click the “Run Query” button:<\/p>\n\n\n\n The 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.<\/p>\n\n\n First, we are going to create a manager<\/em> user. Select the GraphQL tab from the left sidebar, copy the following mutation into the GraphQL Playground, and click the “Play” button:<\/p>\n\n\n\n Your screen should look like this:<\/p>\n\n\n\n Next, let\u2019s create an employee<\/em> user by running the following mutation through the GraphQL Playground editor:<\/p>\n\n\n\n You should see the following response:<\/p>\n\n\n\n Now, let\u2019s create a confidential<\/em> file by running the following mutation:<\/p>\n\n\n\n As a response, you should get the following:<\/p>\n\n\n\n And lastly, create a public<\/em> file with the following mutation:<\/p>\n\n\n\n If successful, it should prompt the following response:<\/p>\n\n\n\n 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: <\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n But what is this “ABAC” system that we just mentioned? What does it stand for, and what can it do?<\/p>\n\n\n ABAC stands for Attribute-Based Access Control<\/em>. As its name indicates, it\u2019s an authorization model that establishes access policies based on attributes<\/em>. 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. <\/p>\n\n\n\n In essence, ABAC allows the definition of fine-grained<\/em> access control policies based on environmental properties and your data. Now that we know what it can do, let\u2019s define some access rules to give you concrete examples.<\/p>\n\n\n In FaunaDB, access rules are defined in the form of roles. A role consists of the following data:<\/p>\n\n\n\n Roles are created through the You can see two important concepts in this role; membership <\/strong>and privileges. <\/strong>Membership defines who receives the privileges of the role and privileges defines what these permissions are. Let\u2019s write a simple example rule to start with: \u201cAny user can read all files.\u201d<\/em><\/p>\n\n\n\n Since the rule applies on all users, we would define the membership like this: <\/p>\n\n\n\n Simple right? We then continue to define the “Can read all files” privilege for all of these users.<\/p>\n\n\n\n The direct effect of this is that any token that you receive by logging in with a user via our 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 Below is the privilege that would only provide read access to non-confidential files: <\/p>\n\n\n\n This directly uses properties of the “File” resource we are trying to access. Since it\u2019s just a function, we could also take into account environmental properties like the current time. For example, let\u2019s write a rule that only allows access on weekdays. <\/p>\n\n\n\n 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 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 \u2014 privileges or membership \u2014 determines their granularity and the attributes that are available, and will differ with each particular use case.<\/p>\n\n\n\n Now that we have covered the basics of how roles work, let\u2019s continue by creating the access rules for our example use case!<\/p>\n\n\n\n In order to keep things neat and tidy, we\u2019re 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.<\/p>\n\n\n\n Let\u2019s implement the first rule: <\/p>\n\n\n\n \u201cAllow employee users to read public files only.\u201d<\/em><\/p>\n\n\n\n In order to create a role meeting these conditions, we are going to use the following query:<\/p>\n\n\n\n Select the Shell tab from the left sidebar, copy the above query into the command panel, and click the “Run Query” button:<\/p>\n\n\n\n Next, let\u2019s implement the second access rule:<\/p>\n\n\n\n \u201cAllow manager users to read both public files and, only during weekdays, confidential files.\u201d<\/em><\/p>\n\n\n\n In this case, we are going to use the following query:<\/p>\n\n\n\n Copy the query into the command panel, and click the “Run Query” button:<\/p>\n\n\n\n At this point, we have created all of the necessary elements for implementing and trying out our example use case! Let\u2019s continue with verifying that the access rules we just created are working as expected…<\/p>\n\n\n Let\u2019s start by checking the first rule: <\/p>\n\n\n\n \u201cAllow employee users to read public files only.\u201d<\/em><\/p>\n\n\n\n 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:<\/p>\n\n\n\n As a response, you should get a secret<\/em> access token. The secret represents that the user has been authenticated successfully:<\/p>\n\n\n\n At this point, it\u2019s 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<\/em> information on its own, but it\u2019s just an authentication<\/em> representation of a given document.<\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n 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<\/em><\/a> as part of the request. To achieve this, we have to modify the Click the plus ( With the secret properly set in the request, let\u2019s try to read all of the files on behalf of the employee user. Run the following query from the GraphQL Playground: <\/p>\n\n\n\n In the response, you should see the public file only:<\/p>\n\n\n\n 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!<\/p>\n\n\n\n Let\u2019s move on now to verifying our second rule:<\/p>\n\n\n\n \u201cAllow manager users to read both public files and, only during weekdays, confidential files.\u201d<\/em><\/p>\n\n\n\n This time, we are going to log in as the employee user. Since the login mutation requires an admin<\/em> secret token, we have to go back first to the original tab containing the default authorization configuration. Once there, run the following query:<\/p>\n\n\n\n You should get a new secret as a response:<\/p>\n\n\n\n Copy the secret, create a new tab, and modify the As long as you\u2019re 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:<\/p>\n\n\n\n And, finally, we have verified that all of the access rules are working successfully from the GraphQL API!<\/p>\n\n\n In this post, we have learned how a comprehensive authorization model can be implemented on top of the FaunaDB<\/a> 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\ntype User {\n username: String! @unique\n role: UserRole!\n}\n\nenum UserRole {\n MANAGER\n EMPLOYEE\n}\n\ntype File {\n content: String!\n confidential: Boolean!\n}\n\ninput CreateUserInput {\n username: String!\n password: String!\n role: UserRole!\n}\n\ninput LoginUserInput {\n username: String!\n password: String!\n}\n\ntype Query {\n allFiles: [File!]!\n}\n\ntype Mutation {\n createUser(input: CreateUserInput): User! @resolver(name: \"create_user\")\n loginUser(input: LoginUserInput): String! @resolver(name: \"login_user\")\n}<\/code><\/pre>\n\n\n\ncreateUser<\/code> and loginUser<\/code> Mutation fields have been annotated with a special directive named @resolver<\/code><\/a>. This is a directive provided by the FaunaDB<\/a> GraphQL API, which allows us to define a custom behavior for a given Query or Mutation field. Since we\u2019ll be using FaunaDB\u2019s built-in authentication mechanisms, we will need to define this logic in FaunaDB<\/a> after we import the schema. <\/p>\n\n\nImporting the schema<\/h3>\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/01-new-database-2-1.png?ssl=1\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/02-new-database-2.png?ssl=1\")
<\/figure>\n\n\n\nschema.gql<\/code> containing the schema definition. Then, select the GRAPHQL tab from the left sidebar, click the “Import Schema” button, and select the newly-created file: <\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/04-import-schema-2.png?ssl=1\")
<\/figure>\n\n\n\nCustom resolvers for authentication<\/h3>\n\n\n
createUser<\/code> and loginUser<\/code> mutation fields that have been annotated with a special directive named @resolver<\/code>. createUser<\/code> 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<\/code> tag.<\/p>\n\n\n\n@resolver(name: \"create_user\")<\/code> we are informing FaunaDB that this mutation is not implemented yet but will be implemented by a User-defined function<\/a> (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.<\/p>\n\n\n\nLogin<\/code> function which returns a token with certain permissions. The permissions that this token holds depend on the access rules that we will write.<\/p>\n\n\n\ncreateUser<\/code> field resolver so that we can create some test users. First, select the Shell tab from the left sidebar:<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/05-shell-2.png?ssl=1\")
<\/figure>\n\n\n\nUpdate(Function(\"create_user\"), {\n \"body\": Query(\n Lambda([\"input\"],\n Create(Collection(\"User\"), {\n data: {\n username: Select(\"username\", Var(\"input\")),\n role: Select(\"role\", Var(\"input\")),\n },\n credentials: {\n password: Select(\"password\", Var(\"input\"))\n }\n }) \n )\n )\n});<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/06-create-user-udf-2.png?ssl=1\")
<\/figure>\n\n\n\ncreate_user<\/code> 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<\/em> 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<\/code><\/a>, as explained next.<\/p>\n\n\n\nloginUser<\/code> field resolver through the following FQL query:<\/p>\n\n\n\nUpdate(Function(\"login_user\"), {\n \"body\": Query(\n Lambda([\"input\"],\n Select(\n \"secret\",\n Login(\n Match(Index(\"unique_User_username\"), Select(\"username\", Var(\"input\"))), \n { password: Select(\"password\", Var(\"input\")) }\n )\n )\n )\n )\n});<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/07-login-user-2.png?ssl=1\")
<\/figure>\n\n\n\nlogin_user<\/code> UDF will attempt to authenticate a User with the given username and password credentials. As mentioned before, it does so via the Login<\/code><\/a> function. The Login<\/code> 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<\/code> UDF returns an authorization token called a secret<\/em> which can be used in subsequent requests for validating the User\u2019s identity.<\/p>\n\n\n\nCreating sample data<\/h3>\n\n\n
mutation CreateManagerUser {\n createUser(input: {\n username: \"bill.lumbergh\"\n password: \"123456\"\n role: MANAGER\n }) {\n username\n role\n }\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/09-create-manager.png?ssl=1\")
<\/figure>\n\n\n\nmutation CreateEmployeeUser {\n createUser(input: {\n username: \"peter.gibbons\"\n password: \"abcdef\"\n role: EMPLOYEE\n }) {\n username\n role\n }\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/10-create-employee-2-2.png?ssl=1\")
<\/figure>\n\n\n\nmutation CreateConfidentialFile {\n createFile(data: {\n content: \"This is a confidential file!\"\n confidential: true\n }) {\n content\n confidential\n }\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/Screen-Shot-2019-11-12-at-15.36.40-3.png?ssl=1\")
<\/figure>\n\n\n\nmutation CreatePublicFile {\n createFile(data: {\n content: \"This is a public file!\"\n confidential: false\n }) {\n content\n confidential\n }\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/12-create-public-file.png?ssl=1\")
<\/figure>\n\n\n\nWhat is ABAC?<\/h3>\n\n\n
Defining the access rules<\/h3>\n\n\n
CreateRole<\/code><\/a> FQL function, as shown in the following example snippet:<\/p>\n\n\n\nCreateRole({\n name: \"role_name\",\n membership: [ \/\/ ... ],\n privileges: [ \/\/ ... ]\n})<\/code><\/pre>\n\n\n\nmembership: {\n resource: Collection(\"User\")\n}<\/code><\/pre>\n\n\n\nprivileges: [\n {\n resource: Collection(\"File\"),\n actions: { read: true }\n }\n]<\/code><\/pre>\n\n\n\nloginUser<\/code> GraphQL mutation can now access all files. <\/p>\n\n\n\n{read: true}<\/code> 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: \u201cA user can only access a file if it is not confidential\u201d. In FaunaDB\u2019s FQL, such a function is written by using Query(Lambda(\u2018x\u2019, \u2026 <logic that users Var(\u2018x\u2019)>))<\/code>.
<\/p>\n\n\n\nprivileges: [\n {\n resource: Collection(\"File\"),\n actions: {\n \/\/ Read and establish rule based on action attribute\n read: Query(\n \/\/ Read and establish rule based on resource attribute\n Lambda(\"fileRef\",\n Not(Select([\"data\", \"confidential\"], Get(Var(\"fileRef\"))))\n )\n )\n }\n }\n]<\/code><\/pre>\n\n\n\nprivileges: [\n {\n resource: Collection(\"File\"),\n actions: {\n read: Query(\n Lambda(\"fileRef\",\n Let(\n {\n dayOfWeek: DayOfWeek(Now())\n },\n And(GTE(Var(\"dayOfWeek\"), 1), LTE(Var(\"dayOfWeek\"), 5)) \n )\n )\n )\n }\n }\n]<\/code><\/pre>\n\n\n\nMANAGER<\/code> role to be part of the role membership. <\/p>\n\n\n\nmembership: {\n resource: Collection(\"User\"),\n predicate: Query( \/\/ Read and establish rule based on user attribute\n Lambda(\"userRef\", \n Equals(Select([\"data\", \"role\"], Get(Var(\"userRef\"))), \"MANAGER\")\n )\n )\n}<\/code><\/pre>\n\n\n\nCreateRole({\n name: \"employee_role\",\n membership: {\n resource: Collection(\"User\"),\n predicate: Query( \n Lambda(\"userRef\",\n \/\/ User attribute based rule:\n \/\/ It grants access only if the User has EMPLOYEE role.\n \/\/ If so, further rules specified in the privileges\n \/\/ section are applied next. \n Equals(Select([\"data\", \"role\"], Get(Var(\"userRef\"))), \"EMPLOYEE\")\n )\n )\n },\n privileges: [\n {\n \/\/ Note: 'allFiles' Index is used to retrieve the \n \/\/ documents from the File collection. Therefore, \n \/\/ read access to the Index is required here as well.\n resource: Index(\"allFiles\"),\n actions: { read: true } \n },\n {\n resource: Collection(\"File\"),\n actions: {\n \/\/ Action attribute based rule:\n \/\/ It grants read access to the File collection.\n read: Query(\n Lambda(\"fileRef\",\n Let(\n {\n file: Get(Var(\"fileRef\")),\n },\n \/\/ Resource attribute based rule:\n \/\/ It grants access to public files only.\n Not(Select([\"data\", \"confidential\"], Var(\"file\")))\n )\n )\n )\n }\n }\n ]\n})<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/08.01-create-employee-role-2.png?ssl=1\")
<\/figure>\n\n\n\nCreateRole({\n name: \"manager_role\",\n membership: {\n resource: Collection(\"User\"),\n predicate: Query(\n Lambda(\"userRef\", \n \/\/ User attribute based rule:\n \/\/ It grants access only if the User has MANAGER role.\n \/\/ If so, further rules specified in the privileges\n \/\/ section are applied next.\n Equals(Select([\"data\", \"role\"], Get(Var(\"userRef\"))), \"MANAGER\")\n )\n )\n },\n privileges: [\n {\n \/\/ Note: 'allFiles' Index is used to retrieve\n \/\/ documents from the File collection. Therefore, \n \/\/ read access to the Index is required here as well.\n resource: Index(\"allFiles\"),\n actions: { read: true } \n },\n {\n resource: Collection(\"File\"),\n actions: {\n \/\/ Action attribute based rule:\n \/\/ It grants read access to the File collection.\n read: Query(\n Lambda(\"fileRef\",\n Let(\n {\n file: Get(Var(\"fileRef\")),\n dayOfWeek: DayOfWeek(Now())\n },\n Or(\n \/\/ Resource attribute based rule:\n \/\/ It grants access to public files.\n Not(Select([\"data\", \"confidential\"], Var(\"file\"))),\n \/\/ Resource and environmental attribute based rule:\n \/\/ It grants access to confidential files only on weekdays.\n And(\n Select([\"data\", \"confidential\"], Var(\"file\")),\n And(GTE(Var(\"dayOfWeek\"), 1), LTE(Var(\"dayOfWeek\"), 5)) \n )\n )\n )\n )\n )\n }\n }\n ]\n})<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/08.02-create-manager-role-2.png?ssl=1\")
<\/figure>\n\n\n\nPutting everything in action<\/h3>\n\n\n
mutation LoginEmployeeUser {\n loginUser(input: {\n username: \"peter.gibbons\"\n password: \"abcdef\"\n })\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/13-login-employee.png?ssl=1\")
<\/figure>\n\n\n\nAuthorization<\/code> header value set by the GraphQL Playground. Since we don\u2019t want to miss the admin secret that is being used as default, we\u2019re going to do this in a new tab.<\/p>\n\n\n\n+<\/code>) button to create a new tab, and select the HTTP HEADERS<\/code> 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<\/em> value from Basic to Bearer as well:<\/p>\n\n\n\n{\n \"authorization\": \"Bearer fnEDdByZ5JACFANyg5uLcAISAtUY6TKlIIb2JnZhkjU-SWEaino\"\n}<\/code><\/pre>\n\n\n\nquery ReadFiles {\n allFiles {\n data {\n content\n confidential\n }\n }\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/14-read-files-employeee.png?ssl=1\")
<\/figure>\n\n\n\nmutation LoginManagerUser {\n loginUser(input: {\n username: \"bill.lumbergh\"\n password: \"123456\"\n })\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/15-login-manager.png?ssl=1\")
<\/figure>\n\n\n\nAuthorization<\/code> 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:<\/p>\n\n\n\nquery ReadFiles {\n allFiles {\n data {\n content\n confidential\n }\n }\n}<\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2020\/02\/16-read-files-manager.png?ssl=1\")
<\/figure>\n\n\n\nConclusion<\/h3>\n\n\n