diff --git a/docs/content/interacting/managing-group-access.mdx b/docs/content/interacting/managing-group-access.mdx index 7d26e0099..10b85faea 100644 --- a/docs/content/interacting/managing-group-access.mdx +++ b/docs/content/interacting/managing-group-access.mdx @@ -23,7 +23,7 @@ import { In this guide you will learn how to grant a group of users access to a particular object. - + Adding a relationship tuple specifying that a group has a relation to an object is helpful in cases where you want to encompass a set of users with the same relation to an object. For example: @@ -34,7 +34,7 @@ Adding a relationship tuple specifying that a group has a relation to an object - Making a `file` viewable for all `users` within an `organization` - Restricting access from or to `users` in a certain `locale` -} /> + ## Before You Start diff --git a/docs/content/interacting/managing-group-membership.mdx b/docs/content/interacting/managing-group-membership.mdx index 389966164..0c2befc7d 100644 --- a/docs/content/interacting/managing-group-membership.mdx +++ b/docs/content/interacting/managing-group-membership.mdx @@ -23,7 +23,7 @@ import { In this guide you will learn how to update a user's membership to a group by adding and removing them from it. - + Suppose: @@ -34,7 +34,7 @@ Suppose: These are cases where using group membership can be helpful as you do not need to iterate over all of the group's resources to add or revoke access to particular objects. You can add a relationship tuple indicating that a user belongs to a group, or delete a tuple to indicate that a user is no longer part of the group. -} /> + ## Before You Start diff --git a/docs/content/interacting/managing-relationships-between-objects.mdx b/docs/content/interacting/managing-relationships-between-objects.mdx index 1bf0b7ce4..7681feb6b 100644 --- a/docs/content/interacting/managing-relationships-between-objects.mdx +++ b/docs/content/interacting/managing-relationships-between-objects.mdx @@ -22,14 +22,14 @@ import { In this guide you will learn how to grant a user access to a particular object through a relationship with another object. - + Giving user access through a relationship with another object is helpful because it allows scaling as the number of object grows. For example: - organization that owns many repos - team that administers many documents -} /> + ## Before you start diff --git a/docs/content/interacting/managing-user-access.mdx b/docs/content/interacting/managing-user-access.mdx index 3719cb7a0..28063a673 100644 --- a/docs/content/interacting/managing-user-access.mdx +++ b/docs/content/interacting/managing-user-access.mdx @@ -23,14 +23,14 @@ import { In this guide you will learn how to grant a access to a particular . - + Granting access with a __ is a core part of . Without any relationship tuples, any __ will fail. You should use: - _authorization model_ to represent what **relation**s are possible between the users and objects in your system - _relationship tuples_ to represent the facts about the relationships between users and objects in your system. -} /> + ## Before You Start diff --git a/docs/content/interacting/transactional-writes.mdx b/docs/content/interacting/transactional-writes.mdx index b9ce9f4bc..a850a8864 100644 --- a/docs/content/interacting/transactional-writes.mdx +++ b/docs/content/interacting/transactional-writes.mdx @@ -23,11 +23,11 @@ import { In this guide you will learn how to update multiple in a single transaction. - + Updating multiple relationship tuples is useful to keep system state consistent. -} /> + ## Before You Start diff --git a/docs/content/modeling/blocklists.mdx b/docs/content/modeling/blocklists.mdx index 2e466e712..1f3144562 100644 --- a/docs/content/modeling/blocklists.mdx +++ b/docs/content/modeling/blocklists.mdx @@ -24,7 +24,7 @@ import { In this guide you'll see how to model preventing users from accessing objects using . For example, `blocking` users from accessing a `document`, even if it has been already shared with them. - + Exclusion is useful while building applications. You may need to support access patterns like granting access to some users, but excluding specific people or groups, similar to how users can block others from following them on social media, or prevent them from sharing documents on Google Drive. @@ -33,7 +33,7 @@ This is useful when: - Implementing the "blocking" feature, such as the profile blocking commonly present on social media platforms (e.g. Instagram and Twitter). - Reduce a user's access if they are part of a particular group (e.g. restricting access to members who are also guests, or restricting access to users in a certain locality). -} /> + ## Before You Start diff --git a/docs/content/modeling/building-blocks/concentric-relationships.mdx b/docs/content/modeling/building-blocks/concentric-relationships.mdx index 71e77a425..ba75348d0 100644 --- a/docs/content/modeling/building-blocks/concentric-relationships.mdx +++ b/docs/content/modeling/building-blocks/concentric-relationships.mdx @@ -25,7 +25,7 @@ In this short guide, you'll learn how to represent a concentric + Concentric relations make the most sense when your domain logic has nested relations, where one having relation implies having another relation. @@ -37,7 +37,7 @@ For example: This allows you to only create a single _relationship tuple_ rather than creating n _relationship tuples_ for each relation. -} /> + ## Before You Start diff --git a/docs/content/modeling/building-blocks/direct-relationships.mdx b/docs/content/modeling/building-blocks/direct-relationships.mdx index b4a9e682b..aab0c5189 100644 --- a/docs/content/modeling/building-blocks/direct-relationships.mdx +++ b/docs/content/modeling/building-blocks/direct-relationships.mdx @@ -25,7 +25,7 @@ import TabItem from '@theme/TabItem'; In this guide you'll learn how to model relationships that may or may not be assigned directly to individual users. - + Disabling _direct relationships_ for a certain relation on an objects are useful especially in cases where you are trying to model some permissions that are not usually granted individually to a user. @@ -33,7 +33,7 @@ This is useful when: - For security reason, not permitting permissions assigned directly to individuals without associating roles -} /> + ## Before You Start diff --git a/docs/content/modeling/building-blocks/object-to-object-relationships.mdx b/docs/content/modeling/building-blocks/object-to-object-relationships.mdx index 4df671d59..cc12cb2bb 100644 --- a/docs/content/modeling/building-blocks/object-to-object-relationships.mdx +++ b/docs/content/modeling/building-blocks/object-to-object-relationships.mdx @@ -23,7 +23,7 @@ import { In this guide you'll learn how to model your application with that are not specifically tied to a user. For example, a `folder` is a `parent` of a `document`. - + This design pattern is helpful in the case where there are relationships between different objects. With , so long as both objects are in a type defined in the , relationship tuples can be added to indicate a relationship between them. @@ -38,7 +38,7 @@ For example: - `account` can contain `transactions` - `buildings` can have `doors` -} /> + ## Before You Start diff --git a/docs/content/modeling/contextual-time-based-authorization.mdx b/docs/content/modeling/contextual-time-based-authorization.mdx index 80412a8b2..2026f1072 100644 --- a/docs/content/modeling/contextual-time-based-authorization.mdx +++ b/docs/content/modeling/contextual-time-based-authorization.mdx @@ -25,14 +25,15 @@ import { This section explores some methods available to you to tackle some use-cases where the expected authorization check may depend on certain dynamic or contextual data (such as time, location, ip address, weather) that have not been written to the store. - + + Contextual Tuples should be used when modeling cases where a user's access to an object depends on the context of their request. For example: - An employee’s ability to access a document when they are connected to the company VPN or the api call is originating from an internal IP address. - A support engineer is only able to access a user's account during office hours. - If a user belongs to multiple organizations, they are only able to access a resource if they set a specific organization in their current context. -} /> + ## Before You Start diff --git a/docs/content/modeling/custom-roles.mdx b/docs/content/modeling/custom-roles.mdx index 83ec0c55f..a2f02aaa4 100644 --- a/docs/content/modeling/custom-roles.mdx +++ b/docs/content/modeling/custom-roles.mdx @@ -25,7 +25,7 @@ In this guide you'll learn how to model custom roles in your system using + In many cases, roles would fit in well as relations on an object type, as seen in [Modeling Roles and Permissions](./roles-and-permissions.mdx). In some cases, however, they may not be enough. @@ -35,7 +35,7 @@ Custom roles are useful when: - It is not known beforehand (at the time of Authorization Model creation) what the application roles are. - The team responsible for building the authorization model is different from the teams responsible for defining roles and access to the application. -} /> + ## Before you start diff --git a/docs/content/modeling/direct-access.mdx b/docs/content/modeling/direct-access.mdx index 7e76946f3..7de265dac 100644 --- a/docs/content/modeling/direct-access.mdx +++ b/docs/content/modeling/direct-access.mdx @@ -23,14 +23,14 @@ import { In this guide you will learn how to grant a access to an (such as a certain document) in . - + Granting access with __ is a core part of . Without them, any __ will fail. You should use: - _authorization model_ to represent what **relation**s are possible between the users and objects in the system - _relationship tuples_ to represent the facts about the relationships between users and objects in your system. -} /> + ## Before you start diff --git a/docs/content/modeling/getting-started.mdx b/docs/content/modeling/getting-started.mdx index 19f294b0c..e88d844ad 100644 --- a/docs/content/modeling/getting-started.mdx +++ b/docs/content/modeling/getting-started.mdx @@ -53,45 +53,23 @@ If that sounds hard, don't worry! We'll guide you through it. ReBAC systems determine access from a to an . Authorization decisions are then yes or no answers to the question: "Does user U have relation R with object O?". - - "Can user U perform an action A on object O?" -

- } - appearance="filled" - /> - - "Does user U have relation R with object O?" -

- } - /> + + "Can user U perform an action A on object O?" + + + "Does user U have relation R with object O?" + In the previous example, a relation R should be defined that implies permission to action A. For example: - - "Can user Jane perform action view on object project sandcastle?" -

- } - appearance="filled" - /> - - "Can user Jane have relation view with object project sandcastle?" -

- } - /> + + "Can user Jane perform action view on object project sandcastle?" + + + "Can user Jane have relation view with object project sandcastle?" + We'll provide more detailed examples throughout this article. @@ -1387,23 +1365,12 @@ How? Remember from the introduction that ** service does that by checking if a user has a particular relationship to an object, based on your authorization model and relationship tuples. - - "Can user U perform action A on object O?" -

- } - appearance="filled" - /> - - "Can user U have relation R with object O?" -

- } - /> + + "Can user U perform action A on object O?" + + + "Can user U have relation R with object O?" + What we want is to ensure that given our current authorization model and some sample relationship tuples, we get the expected results for those questions. diff --git a/docs/content/modeling/multiple-restrictions.mdx b/docs/content/modeling/multiple-restrictions.mdx index 5d42f0e53..6fa9b536f 100644 --- a/docs/content/modeling/multiple-restrictions.mdx +++ b/docs/content/modeling/multiple-restrictions.mdx @@ -28,14 +28,14 @@ For example, __ are In this way, we prevent other users from deleting such document. - + This is useful when: - Limiting certain actions (such as deleting or reading sensitive document) to privileged users. - Adding restrictions and requiring multiple authorization paths before granting access. -} /> + ## Before You Start diff --git a/docs/content/modeling/organization-context-authorization.mdx b/docs/content/modeling/organization-context-authorization.mdx index cdffa2aac..806896ec3 100644 --- a/docs/content/modeling/organization-context-authorization.mdx +++ b/docs/content/modeling/organization-context-authorization.mdx @@ -25,14 +25,14 @@ import { This section tackles cases where a user may have access to a particular resource through their presence in a particular organization, and they should have that access only when logged in within the context of that organization. - + Contextual Tuples should be used when modeling cases where a user's access to an object depends on the context of their request. For example: - An employee’s ability to access a document when they are connected to the organization VPN or the api call is originating from an internal IP address. - A support engineer is only able to access a user's account during office hours. - If a user belongs to multiple organizations, they are only able to access a resource if they set a specific organization in their current context. -} /> + ## Before You Start diff --git a/docs/content/modeling/parent-child.mdx b/docs/content/modeling/parent-child.mdx index 11d959f71..b14870ab5 100644 --- a/docs/content/modeling/parent-child.mdx +++ b/docs/content/modeling/parent-child.mdx @@ -23,7 +23,7 @@ import { In this guide you will learn how to indicate between , and how users' relationships to one object can affect their relationship with another. For example: how a `editor` of a `folder` can be an `editor` of all `documents` the `folder` is a `parent` of. - + Object-to-Object relationships, combined with a configured authorization model can be used to indicate that a user's relation with one object can influence their relationship with another object. This can also be used in some cases to remove the need to modify relations between objects using [user groups](./user-groups.mdx#03-assign-the-team-members-a-relation-to-an-object). @@ -33,7 +33,7 @@ Object-to-object relationships can be used: - To indicate that users who have a repository admin role (`repo_admin`) in an organization automatically have `admin` access to all repositories in that organization - To indicate that users who are `subscribed` to a `plan`, get access to all the `features` in that `plan` -} /> + ## Before You Start diff --git a/docs/content/modeling/public-access.mdx b/docs/content/modeling/public-access.mdx index 94854df3b..9aff3ecdf 100644 --- a/docs/content/modeling/public-access.mdx +++ b/docs/content/modeling/public-access.mdx @@ -24,7 +24,7 @@ import { In this guide you will learn how to grant public access to an , such as a certain document, using . - + Public access allows your application to grant every user in the system access to an object. You would add a relationship tuple with type-bound public access when: @@ -33,7 +33,7 @@ Public access allows your application to grant every user in the system access t - a blog `post` is published and anyone should be able to `read` it - a `video` is made public for anyone to `watch` -} /> + ## Before You Start diff --git a/docs/content/modeling/roles-and-permissions.mdx b/docs/content/modeling/roles-and-permissions.mdx index bd3fe5bc7..c10e0a83d 100644 --- a/docs/content/modeling/roles-and-permissions.mdx +++ b/docs/content/modeling/roles-and-permissions.mdx @@ -28,7 +28,7 @@ In this guide you will learn how to model roles and permissions model within + When trying to create a role and permissions model within .: @@ -46,7 +46,7 @@ There are advantages to implementing roles and permissions within } /> + ## Before you start diff --git a/docs/content/modeling/user-groups.mdx b/docs/content/modeling/user-groups.mdx index 8e3bd2bd3..42a6213fe 100644 --- a/docs/content/modeling/user-groups.mdx +++ b/docs/content/modeling/user-groups.mdx @@ -23,7 +23,7 @@ import { In this guide you will learn how to add users to groups and grant groups access to an using . - + Adding a relationship tuple specifying that a group has a relation to an object is helpful in cases where you want to encompass a set of users with the same relation to an object. For example: @@ -34,7 +34,7 @@ Adding a relationship tuple specifying that a group has a relation to an object - Making a `file` viewable for all `users` within an `organization` - Restricting access from or to `users` in a certain `locale` -} /> + ## Before you start diff --git a/src/components/Docs/CardBox/CardBox.module.css b/src/components/Docs/CardBox/CardBox.module.css index 17a52720a..e4476bfab 100644 --- a/src/components/Docs/CardBox/CardBox.module.css +++ b/src/components/Docs/CardBox/CardBox.module.css @@ -12,9 +12,8 @@ .documentation-card-box-children { margin: 0 !important; font-size: 16px; - font-weight: 500; + font-weight: 400; line-height: 28px; - letter-spacing: -0.1px; } .documentation-card-box-children-small ul { padding-left: 14px;