diff --git a/docs/docs/api-overview/data/read-relationships.md b/docs/docs/api-overview/data/read-relationships.md index f59a3d57a..7044b380a 100644 --- a/docs/docs/api-overview/data/read-relationships.md +++ b/docs/docs/api-overview/data/read-relationships.md @@ -18,7 +18,7 @@ POST /v1/tenants/{tenant_id}/data/relationships/read | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/docs/api-overview/permission/check-api.md b/docs/docs/api-overview/permission/check-api.md index c6bfed58f..6003bdecd 100644 --- a/docs/docs/api-overview/permission/check-api.md +++ b/docs/docs/api-overview/permission/check-api.md @@ -187,7 +187,7 @@ Rather than **or**, if we had an **and** relation then Permify Engine waits the With the right architecture we expect **7-12 ms** latency. Depending on your load, cache usage and architecture you can get up to **30ms**. -Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](../../reference/cache.md) +Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](../../reference/cache.md) ## Need any help ? diff --git a/docs/docs/comparision.md b/docs/docs/comparison.md similarity index 100% rename from docs/docs/comparision.md rename to docs/docs/comparison.md diff --git a/docs/docs/installation/google.md b/docs/docs/installation/google.md index deb30dc91..aae009cd6 100644 --- a/docs/docs/installation/google.md +++ b/docs/docs/installation/google.md @@ -117,7 +117,7 @@ This guide outlines the process of deploying Permify, on Google Compute Engine. status: {} ``` -2. Apply service manfiest +2. Apply service manifest ```bash kubectl apply -f service.yaml diff --git a/docs/docs/reference/glossary.md b/docs/docs/reference/glossary.md index a21ec9b12..f27b7bf86 100644 --- a/docs/docs/reference/glossary.md +++ b/docs/docs/reference/glossary.md @@ -10,7 +10,7 @@ This section explains the basic concepts that commonly mentioned in Permify, as [Google Zanzibar] is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps. -Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionaly, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. +Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionally, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. For more about Zanzibar check our blog post, [Google Zanzibar In A Nutshell] diff --git a/docs/docs/reference/snap-tokens.md b/docs/docs/reference/snap-tokens.md index 95eec606e..1cb0fee83 100644 --- a/docs/docs/reference/snap-tokens.md +++ b/docs/docs/reference/snap-tokens.md @@ -1,7 +1,6 @@ - # Snap Tokens & Zookies -A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. +A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. ## Why you should use Snap Tokens ? @@ -11,19 +10,19 @@ Performance standards can be achievable with caching. In Permify, the cache mech Still, all caches suffer from the risk of becoming stale. If some schema update happens, or relations change then all of the caches should be updated according to it to prevent false positive or false negative results. -Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. +Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. To achieve this, we developed tokens called Snap Tokens that consist of a timestamp that is compared in access checks to ensure that the snapshot of the access control is at least as fresh as the resource timestamp - basically its stored snap token. ## How to use Snap Tokens -Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. +Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. -The general workflow for using snap token is getting the snap token from the reponse of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. +The general workflow for using snap token is getting the snap token from the response of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. Then this snap token can be used in endpoints. For example it can be used in access control check with sending via `snap_token` field to ensure getting check result as fresh as previous request. -```json +```json { "schema_version": "ce8siqtmmud16etrelag", "snap_token": "gp/twGSvLBc=", @@ -34,8 +33,8 @@ Then this snap token can be used in endpoints. For example it can be used in acc "permission": "edit", "subject": { "type": "user", - "id": "1", - }, + "id": "1" + } } ``` @@ -54,6 +53,6 @@ check_{TRANSACTION_ID}_{schema_version}_{context}_organization:1#admin@user:1 -> When the second request arrives, since a transaction ID was not provided, the latest transaction ID will again be requested from the database. However, since the first request has already written the example above to the cache, and the second request will generate the same hash, this result will be retrieved from the cache. -## More on Cache Mechanism +## More on Cache Mechanism -Permify implements several cache mecnanisims in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](./cache.md) \ No newline at end of file +Permify implements several cache mecnanisims in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](./cache.md) diff --git a/docs/docs/use-cases/_list.json b/docs/docs/use-cases/_list.json index 7b6e7fb11..853f367a9 100644 --- a/docs/docs/use-cases/_list.json +++ b/docs/docs/use-cases/_list.json @@ -2,7 +2,7 @@ { "id": 1, "title": "Role Based Access Control (RBAC)", - "description": "Want to implement role to your application ? Define an entity and manage your roles throught your applications.", + "description": "Want to implement role to your application ? Define an entity and manage your roles throughout your applications.", "link": "./simple-rbac" }, { diff --git a/docs/versioned_docs/version-0.2.x/api-overview/check-api.md b/docs/versioned_docs/version-0.2.x/api-overview/check-api.md index b9d9b56c2..f15ae11d4 100644 --- a/docs/versioned_docs/version-0.2.x/api-overview/check-api.md +++ b/docs/versioned_docs/version-0.2.x/api-overview/check-api.md @@ -18,7 +18,7 @@ In this section we'll investigate proior check request of Permify: **resource ba | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | permission | string | - | the action the user wants to perform on the resource | -| [x] | subject | object | - | the user or user set who wants to take the action. It containes type and id of the subject. | +| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | | [ ] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop| #### Request diff --git a/docs/versioned_docs/version-0.2.x/api-overview/delete-relationships.md b/docs/versioned_docs/version-0.2.x/api-overview/delete-relationships.md index 17474d7ea..1d5b9fbb0 100644 --- a/docs/versioned_docs/version-0.2.x/api-overview/delete-relationships.md +++ b/docs/versioned_docs/version-0.2.x/api-overview/delete-relationships.md @@ -11,7 +11,7 @@ You can delete any stored relation tuples with following path |----------|----------|---------|---------|-------------------------------------------------------------------------------------------| | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || #### Request diff --git a/docs/versioned_docs/version-0.2.x/api-overview/read-api.md b/docs/versioned_docs/version-0.2.x/api-overview/read-api.md index 2044a6162..48031edf9 100644 --- a/docs/versioned_docs/version-0.2.x/api-overview/read-api.md +++ b/docs/versioned_docs/version-0.2.x/api-overview/read-api.md @@ -12,7 +12,7 @@ Read API allows for directly querying the stored graph data to display and filte | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || #### Request diff --git a/docs/versioned_docs/version-0.2.x/example-use-cases/parent-child.md b/docs/versioned_docs/version-0.2.x/example-use-cases/parent-child.md index 88ecd8b03..66892dc66 100644 --- a/docs/versioned_docs/version-0.2.x/example-use-cases/parent-child.md +++ b/docs/versioned_docs/version-0.2.x/example-use-cases/parent-child.md @@ -94,7 +94,7 @@ We want only, - Students that take that class - Teachers, whom is teacher of the student that takes that specific class (class member). -can access to calendar of that spesific class. +can access to calendar of that specific class. ```perm entity class { @@ -104,7 +104,7 @@ entity class { } ``` -Since ``member` represents the relation with student entitiy. It can reach its relations with comma. So, +Since ``member` represents the relation with student entity. It can reach its relations with comma. So, - ``member.self`` indicates student itself, whom takes that class. diff --git a/docs/versioned_docs/version-0.2.x/example-use-cases/user-groups.md b/docs/versioned_docs/version-0.2.x/example-use-cases/user-groups.md index ed2596490..67de69ec7 100644 --- a/docs/versioned_docs/version-0.2.x/example-use-cases/user-groups.md +++ b/docs/versioned_docs/version-0.2.x/example-use-cases/user-groups.md @@ -110,7 +110,7 @@ entity team { #### project entity -Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entites, parent team and parent organization. +Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entities, parent team and parent organization. ```perm entity project { @@ -129,7 +129,7 @@ Permify Schema supports ***and***, ***or***, ***and not*** and ***or not*** oper #### team actions -- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team spesific resources. +- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team specific resources. - Moreover, for inviting a colleague to a team you must have ***admin role*** and either be a ***owner*** or ***member*** on that team. diff --git a/docs/versioned_docs/version-0.2.x/getting-started/enforcement.md b/docs/versioned_docs/version-0.2.x/getting-started/enforcement.md index c2f807ac6..e5e0543b0 100644 --- a/docs/versioned_docs/version-0.2.x/getting-started/enforcement.md +++ b/docs/versioned_docs/version-0.2.x/getting-started/enforcement.md @@ -139,7 +139,7 @@ Rather than **or**, if we had an **and** relation then Permify Engine waits the For this access check you can ask questions in form of “Which resources can user:X do action Y?” And you’ll get a entity results in a format of string array or as a streaming response depending on the endpoint you're using. -So we have a 2 seperate endpoints for data filtering check request, +So we have a 2 separate endpoints for data filtering check request, - [/v1/permissions/lookup-entity](#lookup-entity) - [/v1/permissions/lookup-entity-stream](#lookup-entity-streaming) diff --git a/docs/versioned_docs/version-0.2.x/installation/brew.md b/docs/versioned_docs/version-0.2.x/installation/brew.md index 8e81d855f..0bf458ef4 100644 --- a/docs/versioned_docs/version-0.2.x/installation/brew.md +++ b/docs/versioned_docs/version-0.2.x/installation/brew.md @@ -4,7 +4,7 @@ title: "Brew (With Conf)" # Brew With Configurations -This section shows how to intall and run Permify Service with using brew. +This section shows how to install and run Permify Service with using brew. ### Install Permify diff --git a/docs/versioned_docs/version-0.2.x/installation/overview.md b/docs/versioned_docs/version-0.2.x/installation/overview.md index 194c12474..8bc568cc7 100644 --- a/docs/versioned_docs/version-0.2.x/installation/overview.md +++ b/docs/versioned_docs/version-0.2.x/installation/overview.md @@ -4,7 +4,7 @@ sidebar_position: 1 # Guide -Permify is an open-source authorization service that you can run in your environment and works as an API. This guide shows how to set up Permify in your servers and use it accross your applications. Set up and implementation consists of 4 steps, +Permify is an open-source authorization service that you can run in your environment and works as an API. This guide shows how to set up Permify in your servers and use it across your applications. Set up and implementation consists of 4 steps, 1. [Set Up & Run Permify Service](#run-permify-api) 2. [Model your Authorization with Permify's DSL, Permify Schema](#model-your-authorization-with-permify-schema) diff --git a/docs/versioned_docs/version-0.2.x/reference/glossary.md b/docs/versioned_docs/version-0.2.x/reference/glossary.md index a4e883a2a..30bfab30b 100644 --- a/docs/versioned_docs/version-0.2.x/reference/glossary.md +++ b/docs/versioned_docs/version-0.2.x/reference/glossary.md @@ -10,7 +10,7 @@ This section explains the basic concepts that commonly mentioned in Permify, as [Google Zanzibar] is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps. -Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionaly, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. +Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionally, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. For more about Zanzibar check our blog post, [Google Zanzibar In A Nutshell] diff --git a/docs/versioned_docs/version-0.2.x/reference/snap-tokens.md b/docs/versioned_docs/version-0.2.x/reference/snap-tokens.md index d9d734f5d..e51a11afc 100644 --- a/docs/versioned_docs/version-0.2.x/reference/snap-tokens.md +++ b/docs/versioned_docs/version-0.2.x/reference/snap-tokens.md @@ -19,7 +19,7 @@ To achieve this, we developed tokens called Snap Tokens that consist of a timest Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. -The general workflow for using snap token is getting the snap token from the reponse of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additioanl column in your relational database. +The general workflow for using snap token is getting the snap token from the response of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. Then this snap token can be used in endpoints. For example it can be used in access control check with sending via `snap_token` field to ensure getting check result as fresh as previous request. diff --git a/docs/versioned_docs/version-0.3.x/api-overview/relationship/delete-relationships.md b/docs/versioned_docs/version-0.3.x/api-overview/relationship/delete-relationships.md index d63b7e683..fb49b60a5 100644 --- a/docs/versioned_docs/version-0.3.x/api-overview/relationship/delete-relationships.md +++ b/docs/versioned_docs/version-0.3.x/api-overview/relationship/delete-relationships.md @@ -14,7 +14,7 @@ You can delete any stored relation tuples with following API | [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/versioned_docs/version-0.3.x/api-overview/relationship/read-api.md b/docs/versioned_docs/version-0.3.x/api-overview/relationship/read-api.md index eb70b30c1..bc91a341a 100644 --- a/docs/versioned_docs/version-0.3.x/api-overview/relationship/read-api.md +++ b/docs/versioned_docs/version-0.3.x/api-overview/relationship/read-api.md @@ -15,7 +15,7 @@ Read API allows for directly querying the stored graph data to display and filte | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/versioned_docs/version-0.3.x/comparision.md b/docs/versioned_docs/version-0.3.x/comparison.md similarity index 100% rename from docs/versioned_docs/version-0.3.x/comparision.md rename to docs/versioned_docs/version-0.3.x/comparison.md diff --git a/docs/versioned_docs/version-0.3.x/installation/brew.md b/docs/versioned_docs/version-0.3.x/installation/brew.md index e73880767..54c46333b 100644 --- a/docs/versioned_docs/version-0.3.x/installation/brew.md +++ b/docs/versioned_docs/version-0.3.x/installation/brew.md @@ -4,7 +4,7 @@ title: "Install with Brew" # Brew With Configurations -This section shows how to intall and run Permify Service with using brew. +This section shows how to install and run Permify Service with using brew. ### Install Permify diff --git a/docs/versioned_docs/version-0.3.x/permify-overview/intro.md b/docs/versioned_docs/version-0.3.x/permify-overview/intro.md index 547ca5d00..90ce1f796 100644 --- a/docs/versioned_docs/version-0.3.x/permify-overview/intro.md +++ b/docs/versioned_docs/version-0.3.x/permify-overview/intro.md @@ -88,7 +88,7 @@ For feature requests, bugs, or any improvements you can always open an issue. ### Want to Contribute? Here are the ways to contribute to Permify * **Contribute to codebase:** We're collaboratively working with our community to make Permify the best it can be! You can develop new features, fix existing issues or make third-party integrations/packages. -* **Improve documentation:** Alongside our codebase, documentation one of the most significant part in our open-source journey. We're trying to give the best DX possible to explain ourselfs and Permify. And you can help on that with importing resources or adding new ones. +* **Improve documentation:** Alongside our codebase, documentation one of the most significant part in our open-source journey. We're trying to give the best DX possible to explain ourselves and Permify. And you can help on that with importing resources or adding new ones. * **Contribute to playground:** Permify playground allows you to visualize and test your authorization logic. You can contribute to our playground by improving its user interface, fixing glitches, or adding new features. You can find more details about contributions on [CONTRIBUTING.md](https://github.com/Permify/permify/blob/master/CONTRIBUTING.md). diff --git a/docs/versioned_docs/version-0.3.x/reference/glossary.md b/docs/versioned_docs/version-0.3.x/reference/glossary.md index a4e883a2a..30bfab30b 100644 --- a/docs/versioned_docs/version-0.3.x/reference/glossary.md +++ b/docs/versioned_docs/version-0.3.x/reference/glossary.md @@ -10,7 +10,7 @@ This section explains the basic concepts that commonly mentioned in Permify, as [Google Zanzibar] is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps. -Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionaly, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. +Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionally, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. For more about Zanzibar check our blog post, [Google Zanzibar In A Nutshell] diff --git a/docs/versioned_docs/version-0.3.x/reference/snap-tokens.md b/docs/versioned_docs/version-0.3.x/reference/snap-tokens.md index 473036673..42260a0e7 100644 --- a/docs/versioned_docs/version-0.3.x/reference/snap-tokens.md +++ b/docs/versioned_docs/version-0.3.x/reference/snap-tokens.md @@ -19,7 +19,7 @@ To achieve this, we developed tokens called Snap Tokens that consist of a timest Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. -The general workflow for using snap token is getting the snap token from the reponse of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. +The general workflow for using snap token is getting the snap token from the response of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. Then this snap token can be used in endpoints. For example it can be used in access control check with sending via `snap_token` field to ensure getting check result as fresh as previous request. diff --git a/docs/versioned_docs/version-0.3.x/use-cases/_list.json b/docs/versioned_docs/version-0.3.x/use-cases/_list.json index 81aacd1ac..2157ed0e5 100644 --- a/docs/versioned_docs/version-0.3.x/use-cases/_list.json +++ b/docs/versioned_docs/version-0.3.x/use-cases/_list.json @@ -2,7 +2,7 @@ { "id": 1, "title": "Role Based Access Control (RBAC)", - "description": "Want to implement role to your application ? Define an entity and manage your roles throught your applications.", + "description": "Want to implement role to your application ? Define an entity and manage your roles throughout your applications.", "link": "./simple-rbac" }, { diff --git a/docs/versioned_docs/version-0.3.x/use-cases/user-groups.md b/docs/versioned_docs/version-0.3.x/use-cases/user-groups.md index 597ab55ba..93c576a80 100644 --- a/docs/versioned_docs/version-0.3.x/use-cases/user-groups.md +++ b/docs/versioned_docs/version-0.3.x/use-cases/user-groups.md @@ -108,7 +108,7 @@ entity team { #### project entity -Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entites, parent team and parent organization. +Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entities, parent team and parent organization. ```perm entity project { @@ -127,7 +127,7 @@ Permify Schema supports ***and***, ***or***, ***and not*** and ***or not*** oper #### team actions -- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team spesific resources. +- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team specific resources. - Moreover, for inviting a colleague to a team you must have ***admin role*** and either be a ***owner*** or ***member*** on that team. diff --git a/docs/versioned_docs/version-0.4.x/api-overview/permission/check-api.md b/docs/versioned_docs/version-0.4.x/api-overview/permission/check-api.md index ab24405cd..ce8847805 100644 --- a/docs/versioned_docs/version-0.4.x/api-overview/permission/check-api.md +++ b/docs/versioned_docs/version-0.4.x/api-overview/permission/check-api.md @@ -16,15 +16,15 @@ In this section we'll look at the resource based check request of Permify. You c **Path:** POST /v1/permissions/check -| Required | Argument | Type | Default | Description | -|----------|-------------------|---------|---------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | -| [ ] | schema_version | string | 8 | Version of the schema | +| Required | Argument | Type | Default | Description | +| -------- | ----------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | +| [ ] | schema_version | string | 8 | Version of the schema | | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../../reference/snap-tokens). | -| [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1. | -| [x] | permission | string | - | the action the user wants to perform on the resource | -| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | -| [x] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop | +| [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1. | +| [x] | permission | string | - | the action the user wants to perform on the resource | +| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | +| [x] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop | | [ ] | contextual_tuples | object | - | Contextual tuples are relations that can be dynamically added to permission request operations. , see more details on [Contextual Tuples](../../../reference/contextual-tuples) | @@ -60,29 +60,31 @@ cr, err: = client.Permission.Check(context.Background(), &v1.PermissionCheckRequ ```javascript -client.permission.check({ - tenantId: "t1", +client.permission + .check({ + tenantId: "t1", metadata: { - snapToken: "", - schemaVersion: "", - depth: 20 + snapToken: "", + schemaVersion: "", + depth: 20, }, entity: { - type: "repository", - id: "1" + type: "repository", + id: "1", }, permission: "edit", subject: { - type: "user", - id: "1" - } -}).then((response) => { + type: "user", + id: "1", + }, + }) + .then((response) => { if (response.can === PermissionCheckResponse_Result.RESULT_ALLOWED) { - console.log("RESULT_ALLOWED") + console.log("RESULT_ALLOWED"); } else { - console.log("RESULT_DENIED") + console.log("RESULT_DENIED"); } -}) + }); ``` @@ -109,6 +111,7 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission }, }' ``` + @@ -121,28 +124,29 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission } ``` -Answering access checks is accomplished within Permify using a basic graph walking mechanism. +Answering access checks is accomplished within Permify using a basic graph walking mechanism. ## How Access Decisions Evaluated? -Access decisions are evaluated by stored [relational tuples] and your authorization model, [Permify Schema]. +Access decisions are evaluated by stored [relational tuples] and your authorization model, [Permify Schema]. + +In high level, access of an subject related with the relationships created between the subject and the resource. You can define this relationships in Permify Schema then create and store them as relational tuples, which is basically your authorization data. -In high level, access of an subject related with the relationships created between the subject and the resource. You can define this relationships in Permify Schema then create and store them as relational tuples, which is basically your authorization data. +Permify Engine to compute access decision in 2 steps, -Permify Engine to compute access decision in 2 steps, 1. Looking up authorization model for finding the given action's ( **edit**, **push**, **delete** etc.) relations. -2. Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action. +2. Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action. -Let's turn back to above authorization question ( ***"Can the user 3 edit document 12 ?"*** ) to better understand how decision evaluation works. +Let's turn back to above authorization question ( **_"Can the user 3 edit document 12 ?"_** ) to better understand how decision evaluation works. [relational tuples]: ../../getting-started/sync-data.md -[Permify Schema]: ../../getting-started/modeling.md +[Permify Schema]: ../../getting-started/modeling.md When Permify Engine receives this question it directly looks up to authorization model to find document `‍edit` action. Let's say we have a model as follows ```perm entity user {} - + entity organization { // organizational roles @@ -154,14 +158,14 @@ entity document { // represents documents parent organization relation parent @organization - + // represents owner of this document relation owner @user - + // permissions action edit = parent.admin or owner action delete = owner -} +} ``` Which has a directed graph as follows: @@ -176,17 +180,16 @@ As we can see above: only users with an admin role in an organization, which `do Since edit action consist **or** between owner and parent.admin, if Permify Engine found user:3 in results of one of these queries then it terminates the other ongoing queries and returns authorized true to the client. -Rather than **or**, if we had an **and** relation then Permify Engine waits the results of these queries to returning a decision. +Rather than **or**, if we had an **and** relation then Permify Engine waits the results of these queries to returning a decision. ## Latency & Performance With the right architecture we expect **7-12 ms** latency. Depending on your load, cache usage and architecture you can get up to **30ms**. -Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](../../reference/cache.md) +Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](../../reference/cache.md) ## Need any help ? :::info Bulk permission check or with other name data filtering is a common use case we have seen so far. If you have a similar use case we would love to hear from you. Join our [discord](https://discord.gg/n6KfzYxhPp) to discuss or [schedule a call with one of our Permify engineers](https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert). ::: - diff --git a/docs/versioned_docs/version-0.4.x/api-overview/relationship/delete-relationships.md b/docs/versioned_docs/version-0.4.x/api-overview/relationship/delete-relationships.md index d63b7e683..fb49b60a5 100644 --- a/docs/versioned_docs/version-0.4.x/api-overview/relationship/delete-relationships.md +++ b/docs/versioned_docs/version-0.4.x/api-overview/relationship/delete-relationships.md @@ -14,7 +14,7 @@ You can delete any stored relation tuples with following API | [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/versioned_docs/version-0.4.x/api-overview/relationship/read-api.md b/docs/versioned_docs/version-0.4.x/api-overview/relationship/read-api.md index eb70b30c1..bc91a341a 100644 --- a/docs/versioned_docs/version-0.4.x/api-overview/relationship/read-api.md +++ b/docs/versioned_docs/version-0.4.x/api-overview/relationship/read-api.md @@ -15,7 +15,7 @@ Read API allows for directly querying the stored graph data to display and filte | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/versioned_docs/version-0.4.x/comparision.md b/docs/versioned_docs/version-0.4.x/comparision.md deleted file mode 100644 index a73e70f98..000000000 --- a/docs/versioned_docs/version-0.4.x/comparision.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: comparison -title: Comparison Between Other Zanzibar implementations ---- - -:::caution Note -This comparison table shows the differentiation between authorization solutions based or inspired by Google Zanzibar paper. If you use any of these solutions and feel the information could be improved, feel free to reach out. -::: - -## General Aspects - -| | Ory/Keto | OpenFGA | SpiceDB | Permify | -|---------------------------------|------------|------------|-----------|-----------| -| **Zanzibar Paper Faithfulness** | Medium | High | High | High | -| **Scalability** | Medium | Medium | High | High | -| **Consistency & Cache** | No Zookies | No Zookies | Supported | Supported | -| **Dev UX** | Average | Average | High | High | - -## Feature Set - -- ✅  Supported, and ready to use with no added configuration or code -- 🟡  Limited support and requires extra user-code to implement. -- ⛔  Not officially supported or documented. - -| | Ory/Keto | OpenFGA | SpiceDB | Permify | -|--------------------------|----------|---------|---------|---------| -| **Check API** | ✅ | ✅ | ✅ | ✅ | -| **Write API** | ✅ | ✅ | ✅ | ✅ | -| **Read API** | ✅ | ✅ | ✅ | ✅ | -| **Expand API** | ✅ | ✅ | ✅ | ✅ | -| **Watch API** | ✅ | ✅ | ✅ | ✅ | -| **RBAC** | ✅ | ✅ | ✅ | ✅ | -| **ReBAC** | ✅ | ✅ | ✅ | ✅ | -| **ABAC** | ⛔ | 🟡 | ✅ | ⛔ | -| **Data Filtering** | ⛔ | ✅ | ✅ | ✅ | -| **Multi Tenancy** | ⛔ | ✅ | ⛔ | ✅ | -| **Testing & Validation** | ⛔ | 🟡 | ✅ | ✅ | -| **Logging & Tracing** | 🟡 | ✅ | ✅ | ✅ | diff --git a/docs/versioned_docs/version-0.4.x/getting-started/enforcement.md b/docs/versioned_docs/version-0.4.x/getting-started/enforcement.md index 9a810df31..f484a3550 100644 --- a/docs/versioned_docs/version-0.4.x/getting-started/enforcement.md +++ b/docs/versioned_docs/version-0.4.x/getting-started/enforcement.md @@ -26,7 +26,7 @@ Permify exposes its APIs via both [gRPC](https://buf.build/permify/permify/docs/ [![View in Swagger](http://jessemillar.github.io/view-in-swagger-button/button.svg)](https://permify.github.io/permify-swagger/) :::info Integration with a Service Mesh -Our software does not include built-in support for service meshes (eg. Istio). +Our software does not include built-in support for service meshes (eg. Istio). However, since it communicates using standard protocols like gRPC and HTTP, it is compatible with Istio and similar service meshes. Users will need to configure their service mesh setup manually to manage traffic for our software within their deployment environment. ::: @@ -72,18 +72,19 @@ These credits are your sole remedy for any availability failures under our SLA. ## Performance & Latency Permify designed to answer these authorization questions efficiently and with minimal complexity while providing low latency with: -- Using its parallel graph engine. + +- Using its parallel graph engine. - Storing the relationships between resources beforehand in Permify data store: [writeDB], rather than providing these relationships at “check” time. - Implementing permission caching to not recompute repeated permission checks, and in memory cache to store authorization schema. - Using [Snap Tokens](../../reference/snap-tokens) to achieve consistency and high performance in cache. -Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisms](../reference/cache.md) +Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](../reference/cache.md) [writeDB]: ../getting-started/sync-data.md ## Request Rate Limits -Default rate limit is set to 100 requests per second. However, users can adjust this based on their specific needs following our documentation. +Default rate limit is set to 100 requests per second. However, users can adjust this based on their specific needs following our documentation. - doc: https://docs.permify.co/docs/reference/configuration - algorithm: https://en.wikipedia.org/wiki/Token_bucket diff --git a/docs/versioned_docs/version-0.4.x/installation/brew.md b/docs/versioned_docs/version-0.4.x/installation/brew.md index c56a06d8b..a7edfc6ba 100644 --- a/docs/versioned_docs/version-0.4.x/installation/brew.md +++ b/docs/versioned_docs/version-0.4.x/installation/brew.md @@ -4,7 +4,7 @@ title: "Install with Brew" # Brew With Configurations -This section shows how to intall and run Permify Service with using brew. +This section shows how to install and run Permify Service with using brew. ### Install Permify diff --git a/docs/versioned_docs/version-0.4.x/installation/google.md b/docs/versioned_docs/version-0.4.x/installation/google.md index deb30dc91..aae009cd6 100644 --- a/docs/versioned_docs/version-0.4.x/installation/google.md +++ b/docs/versioned_docs/version-0.4.x/installation/google.md @@ -117,7 +117,7 @@ This guide outlines the process of deploying Permify, on Google Compute Engine. status: {} ``` -2. Apply service manfiest +2. Apply service manifest ```bash kubectl apply -f service.yaml diff --git a/docs/versioned_docs/version-0.4.x/permify-overview/intro.md b/docs/versioned_docs/version-0.4.x/permify-overview/intro.md index 5c6e69690..ab8dad8eb 100644 --- a/docs/versioned_docs/version-0.4.x/permify-overview/intro.md +++ b/docs/versioned_docs/version-0.4.x/permify-overview/intro.md @@ -100,7 +100,7 @@ For feature requests, bugs, or any improvements you can always open an issue. ### Want to Contribute? Here are the ways to contribute to Permify * **Contribute to codebase:** We're collaboratively working with our community to make Permify the best it can be! You can develop new features, fix existing issues or make third-party integrations/packages. -* **Improve documentation:** Alongside our codebase, documentation one of the most significant part in our open-source journey. We're trying to give the best DX possible to explain ourselfs and Permify. And you can help on that with importing resources or adding new ones. +* **Improve documentation:** Alongside our codebase, documentation one of the most significant part in our open-source journey. We're trying to give the best DX possible to explain ourselves and Permify. And you can help on that with importing resources or adding new ones. * **Contribute to playground:** Permify playground allows you to visualize and test your authorization logic. You can contribute to our playground by improving its user interface, fixing glitches, or adding new features. You can find more details about contributions on [CONTRIBUTING.md](https://github.com/Permify/permify/blob/master/CONTRIBUTING.md). diff --git a/docs/versioned_docs/version-0.4.x/reference/contextual-tuples.md b/docs/versioned_docs/version-0.4.x/reference/contextual-tuples.md index d92c536db..4c26ad946 100644 --- a/docs/versioned_docs/version-0.4.x/reference/contextual-tuples.md +++ b/docs/versioned_docs/version-0.4.x/reference/contextual-tuples.md @@ -3,7 +3,7 @@ import TabItem from '@theme/TabItem'; # Contextual Tuples (Dynamic Permissions) -## What is it ? +## What is it ? Contextual tuples are relations that can be dynamically added to permission request operations. When you send these relations along with your requests, they get processed alongside existing relations in the database and will return a result. @@ -11,9 +11,9 @@ You can utilize Contextual Tuples in authorization checks that depend on certain ## Use Case -Let's give an example to better understand the usage of Contextual Tuples aka dynamic permissions in access checks. +Let's give an example to better understand the usage of Contextual Tuples aka dynamic permissions in access checks. -Consider you're modeling an permission system for an internal application that belongs to an multi regional organization. +Consider you're modeling an permission system for an internal application that belongs to an multi regional organization. ### Authorization Model @@ -64,7 +64,7 @@ entity ip_address_range { A quick breakdown we define **type** for contextual variable `ip_address_range` and related them with user. Afterwards call that dynamic entities inside our organization entity and form the `view_employee` permission as follows: -```perm +```perm action view_employee = hr_manager and ip_address_range.user ``` @@ -74,8 +74,8 @@ Since we cannot create relation statically for `ip_address_range` we need to sen So let's say user Ashley trying to view employee X. And lets assume that, -* She has a **manager** relation in HR department with the tuple `organization:1#hr_manager@user:1` -* She connected to VPN which connected to network 192.158.1.38 - which is Branch's internal network. +- She has a **manager** relation in HR department with the tuple `organization:1#hr_manager@user:1` +- She connected to VPN which connected to network 192.158.1.38 - which is Branch's internal network. @@ -134,53 +134,55 @@ cr, err: = client.Permission.Check(context.Background(), &v1.PermissionCheckRequ ```javascript -client.permission.check({ - tenantId: "t1", +client.permission + .check({ + tenantId: "t1", metadata: { - snapToken: "", - schemaVersion: "", - depth: 20 + snapToken: "", + schemaVersion: "", + depth: 20, }, entity: { - type: "organization", - id: "1" + type: "organization", + id: "1", }, permission: "view_employee", subject: { - type: "user", - id: "1" + type: "user", + id: "1", }, contextualTuples: [ - { - entity: { - type: "organization", - id: "1" - }, - relation: "ip_address_range", - subject: { - type: "ip_address_range", - id: "192.158.1.38", - } + { + entity: { + type: "organization", + id: "1", }, - { - entity: { - type: "ip_address_range", - id: "192.158.1.38" - }, - relation: "user", - subject: { - type: "user", - id: "1", - } - } - ] -}).then((response) => { + relation: "ip_address_range", + subject: { + type: "ip_address_range", + id: "192.158.1.38", + }, + }, + { + entity: { + type: "ip_address_range", + id: "192.158.1.38", + }, + relation: "user", + subject: { + type: "user", + id: "1", + }, + }, + ], + }) + .then((response) => { if (response.can === PermissionCheckResponse_Result.RESULT_ALLOWED) { - console.log("RESULT_ALLOWED") + console.log("RESULT_ALLOWED"); } else { - console.log("RESULT_DENIED") + console.log("RESULT_DENIED"); } -}) + }); ``` @@ -235,12 +237,12 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission -A quick note, +A quick note, -When you use contextual tuples, the cache system will not be operational. This is because the cache system is written along with snapshots and if contextual tuples are written, using the cache would lead to incorrect results. +When you use contextual tuples, the cache system will not be operational. This is because the cache system is written along with snapshots and if contextual tuples are written, using the cache would lead to incorrect results. -Hence, to prevent this, the use of the cache is blocked at the time of the request. See more on the section [Permify Cache Mechanisims](./cache.md) +Hence, to prevent this, the use of the cache is blocked at the time of the request. See more in the section [Permify Cache Mechanisms](./cache.md) ## Need any help ? -Our team is happy to help you get started with Permify. If you'd like to learn more about using Permify in your app or have any questions about this example, [schedule a call with one of our Permify engineer](https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert). \ No newline at end of file +Our team is happy to help you get started with Permify. If you'd like to learn more about using Permify in your app or have any questions about this example, [schedule a call with one of our Permify engineer](https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert). diff --git a/docs/versioned_docs/version-0.4.x/reference/glossary.md b/docs/versioned_docs/version-0.4.x/reference/glossary.md index a4e883a2a..30bfab30b 100644 --- a/docs/versioned_docs/version-0.4.x/reference/glossary.md +++ b/docs/versioned_docs/version-0.4.x/reference/glossary.md @@ -10,7 +10,7 @@ This section explains the basic concepts that commonly mentioned in Permify, as [Google Zanzibar] is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps. -Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionaly, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. +Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionally, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. For more about Zanzibar check our blog post, [Google Zanzibar In A Nutshell] diff --git a/docs/versioned_docs/version-0.4.x/reference/snap-tokens.md b/docs/versioned_docs/version-0.4.x/reference/snap-tokens.md index 919974f5b..f8fc4f613 100644 --- a/docs/versioned_docs/version-0.4.x/reference/snap-tokens.md +++ b/docs/versioned_docs/version-0.4.x/reference/snap-tokens.md @@ -1,7 +1,6 @@ - # Snap Tokens & Zookies -A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. +A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. ## Why you should use Snap Tokens ? @@ -11,19 +10,19 @@ Performance standards can be achievable with caching. In Permify, the cache mech Still, all caches suffer from the risk of becoming stale. If some schema update happens, or relations change then all of the caches should be updated according to it to prevent false positive or false negative results. -Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. +Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. To achieve this, we developed tokens called Snap Tokens that consist of a timestamp that is compared in access checks to ensure that the snapshot of the access control is at least as fresh as the resource timestamp - basically its stored snap token. ## How to use Snap Tokens -Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. +Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. The general workflow for using snap token is getting the snap token from the response of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. Then this snap token can be used in endpoints. For example it can be used in access control check with sending via `snap_token` field to ensure getting check result as fresh as previous request. -```json +```json { "schema_version": "ce8siqtmmud16etrelag", "snap_token": "gp/twGSvLBc=", @@ -34,21 +33,20 @@ Then this snap token can be used in endpoints. For example it can be used in acc "permission": "edit", "subject": { "type": "user", - "id": "1", - }, + "id": "1" + } } ``` [Write API]: ../../api-overview/relationship/write-relationships [Check API]: ../../api-overview/permission/check-api -#### All endpoints that used snap token +#### All endpoints that used snap token -- [Write API](../../api-overview/relationship/write-relationships) +- [Write API](../../api-overview/relationship/write-relationships) - [Check API](../../api-overview/permission/check-api) - [Expand API](../../api-overview/permission/expand-api) +## More on Cache Mechanism -## More on Cache Mechanism - -Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisms](./cache.md) \ No newline at end of file +Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](./cache.md) diff --git a/docs/versioned_docs/version-0.4.x/use-cases/_list.json b/docs/versioned_docs/version-0.4.x/use-cases/_list.json index 7b6e7fb11..853f367a9 100644 --- a/docs/versioned_docs/version-0.4.x/use-cases/_list.json +++ b/docs/versioned_docs/version-0.4.x/use-cases/_list.json @@ -2,7 +2,7 @@ { "id": 1, "title": "Role Based Access Control (RBAC)", - "description": "Want to implement role to your application ? Define an entity and manage your roles throught your applications.", + "description": "Want to implement role to your application ? Define an entity and manage your roles throughout your applications.", "link": "./simple-rbac" }, { diff --git a/docs/versioned_docs/version-0.4.x/use-cases/abac.md b/docs/versioned_docs/version-0.4.x/use-cases/abac.md index e3945ec07..4ce802922 100644 --- a/docs/versioned_docs/version-0.4.x/use-cases/abac.md +++ b/docs/versioned_docs/version-0.4.x/use-cases/abac.md @@ -433,7 +433,7 @@ docker pull **ghcr.io/permify/permify-beta:latest** ```yaml schema: >- - {string schem} + {string scheme} relationships: - entity_name:entity_id#relation@subject_type:subject_id diff --git a/docs/versioned_docs/version-0.4.x/use-cases/rebac.md b/docs/versioned_docs/version-0.4.x/use-cases/rebac.md index 146d8b64b..cbad6e2ab 100644 --- a/docs/versioned_docs/version-0.4.x/use-cases/rebac.md +++ b/docs/versioned_docs/version-0.4.x/use-cases/rebac.md @@ -338,7 +338,7 @@ entity team { ##### project entity -Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entites, parent team and parent organization. +Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entities, parent team and parent organization. ```perm entity project { @@ -357,7 +357,7 @@ Permify Schema supports ***and***, ***or*** and ***not*** operators to define ac ##### team actions -- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team spesific resources. +- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team specific resources. - Moreover, for inviting a colleague to a team you must have ***admin role*** and either be a ***owner*** or ***member*** on that team. diff --git a/docs/versioned_docs/version-0.4.x/use-cases/user-groups.md b/docs/versioned_docs/version-0.4.x/use-cases/user-groups.md index aa48ce152..d31057ea6 100644 --- a/docs/versioned_docs/version-0.4.x/use-cases/user-groups.md +++ b/docs/versioned_docs/version-0.4.x/use-cases/user-groups.md @@ -108,7 +108,7 @@ entity team { #### project entity -Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entites, parent team and parent organization. +Project entity has ``team`` and ``org`` relations. Both these relations represents parent relationship with other entities, parent team and parent organization. ```perm entity project { @@ -127,7 +127,7 @@ Permify Schema supports ***and***, ***or*** and ***not*** operators to define ac #### team actions -- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team spesific resources. +- Only organization ***admin (admin role)*** and ***team owner*** can perform editing and deleting team specific resources. - Moreover, for inviting a colleague to a team you must have ***admin role*** and either be a ***owner*** or ***member*** on that team. diff --git a/docs/versioned_docs/version-0.5.x/api-overview/data/read-relationships.md b/docs/versioned_docs/version-0.5.x/api-overview/data/read-relationships.md index 384f766f9..43409f291 100644 --- a/docs/versioned_docs/version-0.5.x/api-overview/data/read-relationships.md +++ b/docs/versioned_docs/version-0.5.x/api-overview/data/read-relationships.md @@ -17,7 +17,7 @@ Read API allows for directly querying the stored graph data to display and filte | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/versioned_docs/version-0.5.x/api-overview/permission/check-api.md b/docs/versioned_docs/version-0.5.x/api-overview/permission/check-api.md index e85b48aff..d7af7975e 100644 --- a/docs/versioned_docs/version-0.5.x/api-overview/permission/check-api.md +++ b/docs/versioned_docs/version-0.5.x/api-overview/permission/check-api.md @@ -18,16 +18,16 @@ In this section we'll look at the resource based check request of Permify. You c [![View in Swagger](http://jessemillar.github.io/view-in-swagger-button/button.svg)](https://permify.github.io/permify-swagger/#/Permission/permissions.check) -| Required | Argument | Type | Default | Description | -|----------|-------------------|---------|---------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | -| [ ] | schema_version | string | 8 | Version of the schema | -| [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../../reference/snap-tokens). | -| [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1. | -| [x] | permission | string | - | the action the user wants to perform on the resource | -| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | -| [x] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop | -| [ ] | context | object | - | Contextual tuples are relations that can be dynamically added to permission request operations. , see more details on [Contextual Tuples](../../../reference/contextual-tuples) | +| Required | Argument | Type | Default | Description | +| -------- | -------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | +| [ ] | schema_version | string | 8 | Version of the schema | +| [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../../reference/snap-tokens). | +| [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1. | +| [x] | permission | string | - | the action the user wants to perform on the resource | +| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | +| [x] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop | +| [ ] | context | object | - | Contextual tuples are relations that can be dynamically added to permission request operations. , see more details on [Contextual Tuples](../../../reference/contextual-tuples) | @@ -62,29 +62,31 @@ cr, err: = client.Permission.Check(context.Background(), &v1.PermissionCheckRequ ```javascript -client.permission.check({ - tenantId: "t1", +client.permission + .check({ + tenantId: "t1", metadata: { - snapToken: "", - schemaVersion: "", - depth: 20 + snapToken: "", + schemaVersion: "", + depth: 20, }, entity: { - type: "repository", - id: "1" + type: "repository", + id: "1", }, permission: "edit", subject: { - type: "user", - id: "1" - } -}).then((response) => { + type: "user", + id: "1", + }, + }) + .then((response) => { if (response.can === PermissionCheckResponse_Result.RESULT_ALLOWED) { - console.log("RESULT_ALLOWED") + console.log("RESULT_ALLOWED"); } else { - console.log("RESULT_DENIED") + console.log("RESULT_DENIED"); } -}) + }); ``` @@ -111,6 +113,7 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission }, }' ``` + @@ -123,28 +126,29 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission } ``` -Answering access checks is accomplished within Permify using a basic graph walking mechanism. +Answering access checks is accomplished within Permify using a basic graph walking mechanism. ## How Access Decisions Evaluated? -Access decisions are evaluated by stored [relational tuples] and your authorization model, [Permify Schema]. +Access decisions are evaluated by stored [relational tuples] and your authorization model, [Permify Schema]. + +In high level, access of an subject related with the relationships or attributes created between the subject and the resource. You can define this data in Permify Schema then create and store them as relational tuples and attributes, which is basically forms your authorization data. -In high level, access of an subject related with the relationships or attributes created between the subject and the resource. You can define this data in Permify Schema then create and store them as relational tuples and attributes, which is basically forms your authorization data. +Permify Engine to compute access decision in 2 steps, -Permify Engine to compute access decision in 2 steps, 1. Looking up authorization model for finding the given action's ( **edit**, **push**, **delete** etc.) relations. -2. Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action. +2. Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action. -Let's turn back to above authorization question ( ***"Can the user 3 edit document 12 ?"*** ) to better understand how decision evaluation works. +Let's turn back to above authorization question ( **_"Can the user 3 edit document 12 ?"_** ) to better understand how decision evaluation works. [relational tuples]: ../../getting-started/sync-data.md -[Permify Schema]: ../../getting-started/modeling.md +[Permify Schema]: ../../getting-started/modeling.md When Permify Engine receives this question it directly looks up to authorization model to find document `‍edit` action. Let's say we have a model as follows ```perm entity user {} - + entity organization { // organizational roles @@ -156,14 +160,14 @@ entity document { // represents documents parent organization relation parent @organization - + // represents owner of this document relation owner @user - + // permissions action edit = parent.admin or owner action delete = owner -} +} ``` Which has a directed graph as follows: @@ -178,17 +182,16 @@ As we can see above: only users with an admin role in an organization, which `do Since edit action consist **or** between owner and parent.admin, if Permify Engine found user:3 in results of one of these queries then it terminates the other ongoing queries and returns authorized true to the client. -Rather than **or**, if we had an **and** relation then Permify Engine waits the results of these queries to returning a decision. +Rather than **or**, if we had an **and** relation then Permify Engine waits the results of these queries to returning a decision. ## Latency & Performance With the right architecture we expect **7-12 ms** latency. Depending on your load, cache usage and architecture you can get up to **30ms**. -Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](../../reference/cache.md) +Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](../../reference/cache.md) ## Need any help ? :::info Bulk permission check or with other name data filtering is a common use case we have seen so far. If you have a similar use case we would love to hear from you. Join our [discord](https://discord.gg/n6KfzYxhPp) to discuss or [schedule a call with one of our Permify engineers](https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert). ::: - diff --git a/docs/versioned_docs/version-0.5.x/comparision.md b/docs/versioned_docs/version-0.5.x/comparison.md similarity index 100% rename from docs/versioned_docs/version-0.5.x/comparision.md rename to docs/versioned_docs/version-0.5.x/comparison.md diff --git a/docs/versioned_docs/version-0.5.x/installation/google.md b/docs/versioned_docs/version-0.5.x/installation/google.md index deb30dc91..aae009cd6 100644 --- a/docs/versioned_docs/version-0.5.x/installation/google.md +++ b/docs/versioned_docs/version-0.5.x/installation/google.md @@ -117,7 +117,7 @@ This guide outlines the process of deploying Permify, on Google Compute Engine. status: {} ``` -2. Apply service manfiest +2. Apply service manifest ```bash kubectl apply -f service.yaml diff --git a/docs/versioned_docs/version-0.5.x/reference/contextual-tuples.md b/docs/versioned_docs/version-0.5.x/reference/contextual-tuples.md index ff3a806b2..9157b1e29 100644 --- a/docs/versioned_docs/version-0.5.x/reference/contextual-tuples.md +++ b/docs/versioned_docs/version-0.5.x/reference/contextual-tuples.md @@ -3,7 +3,7 @@ import TabItem from '@theme/TabItem'; # Context (Dynamic Permissions) -## What is it ? +## What is it ? Contextual tuples are relations that can be dynamically added to permission request operations. When you send these relations along with your requests, they get processed alongside existing relations in the database and will return a result. @@ -11,9 +11,9 @@ You can utilize Contextual Tuples in authorization checks that depend on certain ## Use Case -Let's give an example to better understand the usage of Contextual Tuples aka dynamic permissions in access checks. +Let's give an example to better understand the usage of Contextual Tuples aka dynamic permissions in access checks. -Consider you're modeling an permission system for an internal application that belongs to an multi regional organization. +Consider you're modeling an permission system for an internal application that belongs to an multi regional organization. ### Authorization Model @@ -64,7 +64,7 @@ entity ip_address_range { A quick breakdown we define **type** for contextual variable `ip_address_range` and related them with user. Afterwards call that dynamic entities inside our organization entity and form the `view_employee` permission as follows: -```perm +```perm action view_employee = hr_manager and ip_address_range.user ``` @@ -74,8 +74,8 @@ Since we cannot create relation statically for `ip_address_range` we need to sen So let's say user Ashley trying to view employee X. And lets assume that, -* She has a **manager** relation in HR department with the tuple `organization:1#hr_manager@user:1` -* She connected to VPN which connected to network 192.158.1.38 - which is Branch's internal network. +- She has a **manager** relation in HR department with the tuple `organization:1#hr_manager@user:1` +- She connected to VPN which connected to network 192.158.1.38 - which is Branch's internal network. @@ -136,55 +136,57 @@ cr, err: = client.Permission.Check(context.Background(), &v1.PermissionCheckRequ ```javascript -client.permission.check({ - tenantId: "t1", +client.permission + .check({ + tenantId: "t1", metadata: { - snapToken: "", - schemaVersion: "", - depth: 20 + snapToken: "", + schemaVersion: "", + depth: 20, }, entity: { - type: "organization", - id: "1" + type: "organization", + id: "1", }, permission: "view_employee", subject: { - type: "user", - id: "1" + type: "user", + id: "1", }, context: { - tuples: [ - { - entity: { - type: "organization", - id: "1" - }, - relation: "ip_address_range", - subject: { - type: "ip_address_range", - id: "192.158.1.38", - } - }, - { - entity: { - type: "ip_address_range", - id: "192.158.1.38" - }, - relation: "user", - subject: { - type: "user", - id: "1", - } - } - ] - } -}).then((response) => { + tuples: [ + { + entity: { + type: "organization", + id: "1", + }, + relation: "ip_address_range", + subject: { + type: "ip_address_range", + id: "192.158.1.38", + }, + }, + { + entity: { + type: "ip_address_range", + id: "192.158.1.38", + }, + relation: "user", + subject: { + type: "user", + id: "1", + }, + }, + ], + }, + }) + .then((response) => { if (response.can === PermissionCheckResponse_Result.RESULT_ALLOWED) { - console.log("RESULT_ALLOWED") + console.log("RESULT_ALLOWED"); } else { - console.log("RESULT_DENIED") + console.log("RESULT_DENIED"); } -}) + }); ``` @@ -241,11 +243,11 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission -A quick note, +A quick note, -When you use contextual tuples, the cache system will not be operational. This is because the cache system is written along with snapshots and if contextual tuples are written, using the cache would lead to incorrect results. +When you use contextual tuples, the cache system will not be operational. This is because the cache system is written along with snapshots and if contextual tuples are written, using the cache would lead to incorrect results. -Hence, to prevent this, the use of the cache is blocked at the time of the request. See more on the section [Permify Cache Mechanisims](./cache.md) +Hence, to prevent this, the use of the cache is blocked at the time of the request. See more in the section [Permify Cache Mechanisms](./cache.md) ## Need any help ? diff --git a/docs/versioned_docs/version-0.5.x/reference/glossary.md b/docs/versioned_docs/version-0.5.x/reference/glossary.md index a21ec9b12..f27b7bf86 100644 --- a/docs/versioned_docs/version-0.5.x/reference/glossary.md +++ b/docs/versioned_docs/version-0.5.x/reference/glossary.md @@ -10,7 +10,7 @@ This section explains the basic concepts that commonly mentioned in Permify, as [Google Zanzibar] is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps. -Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionaly, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. +Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionally, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. For more about Zanzibar check our blog post, [Google Zanzibar In A Nutshell] diff --git a/docs/versioned_docs/version-0.5.x/reference/snap-tokens.md b/docs/versioned_docs/version-0.5.x/reference/snap-tokens.md index 8f1a21786..145681726 100644 --- a/docs/versioned_docs/version-0.5.x/reference/snap-tokens.md +++ b/docs/versioned_docs/version-0.5.x/reference/snap-tokens.md @@ -1,7 +1,6 @@ - # Snap Tokens & Zookies -A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. +A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. ## Why you should use Snap Tokens ? @@ -11,19 +10,19 @@ Performance standards can be achievable with caching. In Permify, the cache mech Still, all caches suffer from the risk of becoming stale. If some schema update happens, or relations change then all of the caches should be updated according to it to prevent false positive or false negative results. -Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. +Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. To achieve this, we developed tokens called Snap Tokens that consist of a timestamp that is compared in access checks to ensure that the snapshot of the access control is at least as fresh as the resource timestamp - basically its stored snap token. ## How to use Snap Tokens -Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. +Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. -The general workflow for using snap token is getting the snap token from the reponse of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. +The general workflow for using snap token is getting the snap token from the response of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. Then this snap token can be used in endpoints. For example it can be used in access control check with sending via `snap_token` field to ensure getting check result as fresh as previous request. -```json +```json { "schema_version": "ce8siqtmmud16etrelag", "snap_token": "gp/twGSvLBc=", @@ -34,20 +33,19 @@ Then this snap token can be used in endpoints. For example it can be used in acc "permission": "edit", "subject": { "type": "user", - "id": "1", - }, + "id": "1" + } } ``` [Write API]: ../../api-overview/data/write-data/ [Check API]: ../../api-overview/permission/check-api -#### All endpoints that used snap token +#### All endpoints that used snap token - [Write API](../../api-overview/data/write-data/) - [Expand API](../../api-overview/permission/expand-api) +## More on Cache Mechanism -## More on Cache Mechanism - -Permify implements several cache mecnanisims in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](./cache.md) \ No newline at end of file +Permify implements several cache mecnanisims in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](./cache.md) diff --git a/docs/versioned_docs/version-0.5.x/use-cases/_list.json b/docs/versioned_docs/version-0.5.x/use-cases/_list.json index 7b6e7fb11..853f367a9 100644 --- a/docs/versioned_docs/version-0.5.x/use-cases/_list.json +++ b/docs/versioned_docs/version-0.5.x/use-cases/_list.json @@ -2,7 +2,7 @@ { "id": 1, "title": "Role Based Access Control (RBAC)", - "description": "Want to implement role to your application ? Define an entity and manage your roles throught your applications.", + "description": "Want to implement role to your application ? Define an entity and manage your roles throughout your applications.", "link": "./simple-rbac" }, { diff --git a/docs/versioned_docs/version-0.6.x/api-overview/data/read-relationships.md b/docs/versioned_docs/version-0.6.x/api-overview/data/read-relationships.md index f59a3d57a..7044b380a 100644 --- a/docs/versioned_docs/version-0.6.x/api-overview/data/read-relationships.md +++ b/docs/versioned_docs/version-0.6.x/api-overview/data/read-relationships.md @@ -18,7 +18,7 @@ POST /v1/tenants/{tenant_id}/data/relationships/read | [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) | | [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1”. | [x] | relation | string | - | relation of the given entity | -| [ ] | subject | object | - | the user or user set. It containes type and id of the subject. || +| [ ] | subject | object | - | the user or user set. It contains type and id of the subject. || diff --git a/docs/versioned_docs/version-0.6.x/api-overview/permission/check-api.md b/docs/versioned_docs/version-0.6.x/api-overview/permission/check-api.md index c6bfed58f..96ffffe70 100644 --- a/docs/versioned_docs/version-0.6.x/api-overview/permission/check-api.md +++ b/docs/versioned_docs/version-0.6.x/api-overview/permission/check-api.md @@ -14,23 +14,24 @@ In this section we'll look at the resource based check request of Permify. You c ## Request -**Path:** +**Path:** + ```javascript -POST /v1/permissions/check +POST / v1 / permissions / check; ``` [![View in Swagger](http://jessemillar.github.io/view-in-swagger-button/button.svg)](https://permify.github.io/permify-swagger/#/Permission/permissions.check) -| Required | Argument | Type | Default | Description | -|----------|-------------------|---------|---------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | -| [ ] | schema_version | string | 8 | Version of the schema | -| [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens.md). | -| [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1. | -| [x] | permission | string | - | the action the user wants to perform on the resource | -| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | -| [x] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop | -| [ ] | context | object | - | Contextual data that can be dynamically added to permission check requests. See details on [Contextual Data](../../reference/contextual-tuples.md) | +| Required | Argument | Type | Default | Description | +| -------- | -------------- | ------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | +| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. | +| [ ] | schema_version | string | 8 | Version of the schema | +| [ ] | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens.md). | +| [x] | entity | object | - | contains entity type and id of the entity. Example: repository:1. | +| [x] | permission | string | - | the action the user wants to perform on the resource | +| [x] | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject. | +| [x] | depth | integer | 8 | Timeout limit when if recursive database queries got in loop | +| [ ] | context | object | - | Contextual data that can be dynamically added to permission check requests. See details on [Contextual Data](../../reference/contextual-tuples.md) | @@ -65,29 +66,31 @@ cr, err: = client.Permission.Check(context.Background(), &v1.PermissionCheckRequ ```javascript -client.permission.check({ - tenantId: "t1", +client.permission + .check({ + tenantId: "t1", metadata: { - snapToken: "", - schemaVersion: "", - depth: 20 + snapToken: "", + schemaVersion: "", + depth: 20, }, entity: { - type: "repository", - id: "1" + type: "repository", + id: "1", }, permission: "edit", subject: { - type: "user", - id: "1" - } -}).then((response) => { + type: "user", + id: "1", + }, + }) + .then((response) => { if (response.can === PermissionCheckResponse_Result.RESULT_ALLOWED) { - console.log("RESULT_ALLOWED") + console.log("RESULT_ALLOWED"); } else { - console.log("RESULT_DENIED") + console.log("RESULT_DENIED"); } -}) + }); ``` @@ -114,6 +117,7 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission }, }' ``` + @@ -126,28 +130,29 @@ curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permission } ``` -Answering access checks is accomplished within Permify using a basic graph walking mechanism. +Answering access checks is accomplished within Permify using a basic graph walking mechanism. ## How Access Decisions Evaluated? -Access decisions are evaluated by stored [relational tuples] and your authorization model, [Permify Schema]. +Access decisions are evaluated by stored [relational tuples] and your authorization model, [Permify Schema]. + +In high level, access of an subject related with the relationships or attributes created between the subject and the resource. You can define this data in Permify Schema then create and store them as relational tuples and attributes, which is basically forms your authorization data. -In high level, access of an subject related with the relationships or attributes created between the subject and the resource. You can define this data in Permify Schema then create and store them as relational tuples and attributes, which is basically forms your authorization data. +Permify Engine to compute access decision in 2 steps, -Permify Engine to compute access decision in 2 steps, 1. Looking up authorization model for finding the given action's ( **edit**, **push**, **delete** etc.) relations. -2. Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action. +2. Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action. -Let's turn back to above authorization question ( ***"Can the user 3 edit document 12 ?"*** ) to better understand how decision evaluation works. +Let's turn back to above authorization question ( **_"Can the user 3 edit document 12 ?"_** ) to better understand how decision evaluation works. [relational tuples]: ../../getting-started/sync-data.md -[Permify Schema]: ../../getting-started/modeling.md +[Permify Schema]: ../../getting-started/modeling.md When Permify Engine receives this question it directly looks up to authorization model to find document `‍edit` action. Let's say we have a model as follows ```perm entity user {} - + entity organization { // organizational roles @@ -159,14 +164,14 @@ entity document { // represents documents parent organization relation parent @organization - + // represents owner of this document relation owner @user - + // permissions action edit = parent.admin or owner action delete = owner -} +} ``` Which has a directed graph as follows: @@ -181,17 +186,16 @@ As we can see above: only users with an admin role in an organization, which `do Since edit action consist **or** between owner and parent.admin, if Permify Engine found user:3 in results of one of these queries then it terminates the other ongoing queries and returns authorized true to the client. -Rather than **or**, if we had an **and** relation then Permify Engine waits the results of these queries to returning a decision. +Rather than **or**, if we had an **and** relation then Permify Engine waits the results of these queries to returning a decision. ## Latency & Performance With the right architecture we expect **7-12 ms** latency. Depending on your load, cache usage and architecture you can get up to **30ms**. -Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](../../reference/cache.md) +Permify implements several cache mechanisms in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](../../reference/cache.md) ## Need any help ? :::info Bulk permission check or with other name data filtering is a common use case we have seen so far. If you have a similar use case we would love to hear from you. Join our [discord](https://discord.gg/n6KfzYxhPp) to discuss or [schedule a call with one of our Permify engineers](https://meetings-eu1.hubspot.com/ege-aytin/call-with-an-expert). ::: - diff --git a/docs/versioned_docs/version-0.6.x/comparision.md b/docs/versioned_docs/version-0.6.x/comparison.md similarity index 100% rename from docs/versioned_docs/version-0.6.x/comparision.md rename to docs/versioned_docs/version-0.6.x/comparison.md diff --git a/docs/versioned_docs/version-0.6.x/installation/google.md b/docs/versioned_docs/version-0.6.x/installation/google.md index deb30dc91..aae009cd6 100644 --- a/docs/versioned_docs/version-0.6.x/installation/google.md +++ b/docs/versioned_docs/version-0.6.x/installation/google.md @@ -117,7 +117,7 @@ This guide outlines the process of deploying Permify, on Google Compute Engine. status: {} ``` -2. Apply service manfiest +2. Apply service manifest ```bash kubectl apply -f service.yaml diff --git a/docs/versioned_docs/version-0.6.x/reference/glossary.md b/docs/versioned_docs/version-0.6.x/reference/glossary.md index a21ec9b12..f27b7bf86 100644 --- a/docs/versioned_docs/version-0.6.x/reference/glossary.md +++ b/docs/versioned_docs/version-0.6.x/reference/glossary.md @@ -10,7 +10,7 @@ This section explains the basic concepts that commonly mentioned in Permify, as [Google Zanzibar] is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps. -Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionaly, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. +Google published Zanzibar back in 2019, and in a short time it gained attention quickly. In fact some big tech companies started to shift their legacy authorization structure to Zanzibar style systems. Additionally, Zanzibar based solutions increased over the time. All disclosure; [Permify] is an authorization system based on Zanzibar. For more about Zanzibar check our blog post, [Google Zanzibar In A Nutshell] diff --git a/docs/versioned_docs/version-0.6.x/reference/snap-tokens.md b/docs/versioned_docs/version-0.6.x/reference/snap-tokens.md index 95eec606e..1cb0fee83 100644 --- a/docs/versioned_docs/version-0.6.x/reference/snap-tokens.md +++ b/docs/versioned_docs/version-0.6.x/reference/snap-tokens.md @@ -1,7 +1,6 @@ - # Snap Tokens & Zookies -A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. +A Snap Token is a token that consists of an encoded timestamp, which is used to ensure fresh results in access control checks. ## Why you should use Snap Tokens ? @@ -11,19 +10,19 @@ Performance standards can be achievable with caching. In Permify, the cache mech Still, all caches suffer from the risk of becoming stale. If some schema update happens, or relations change then all of the caches should be updated according to it to prevent false positive or false negative results. -Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. +Permify avoids this problem with an approach of snapshot reads. Simply, it ensures that access control is evaluated at a consistent point in time to prevent inconsistency. To achieve this, we developed tokens called Snap Tokens that consist of a timestamp that is compared in access checks to ensure that the snapshot of the access control is at least as fresh as the resource timestamp - basically its stored snap token. ## How to use Snap Tokens -Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. +Snap Tokens used in endpoints to represent the snapshot and get fresh results of the API's. It mainly used in [Write API] and [Check API]. -The general workflow for using snap token is getting the snap token from the reponse of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. +The general workflow for using snap token is getting the snap token from the response of Write API request - basically when writing a relational tuple - then mapped it with the resource. One way of doing that is storing snap token in the additional column in your relational database. Then this snap token can be used in endpoints. For example it can be used in access control check with sending via `snap_token` field to ensure getting check result as fresh as previous request. -```json +```json { "schema_version": "ce8siqtmmud16etrelag", "snap_token": "gp/twGSvLBc=", @@ -34,8 +33,8 @@ Then this snap token can be used in endpoints. For example it can be used in acc "permission": "edit", "subject": { "type": "user", - "id": "1", - }, + "id": "1" + } } ``` @@ -54,6 +53,6 @@ check_{TRANSACTION_ID}_{schema_version}_{context}_organization:1#admin@user:1 -> When the second request arrives, since a transaction ID was not provided, the latest transaction ID will again be requested from the database. However, since the first request has already written the example above to the cache, and the second request will generate the same hash, this result will be retrieved from the cache. -## More on Cache Mechanism +## More on Cache Mechanism -Permify implements several cache mecnanisims in order to achieve low latency in scaled distributed systems. See more on the section [Cache Mechanisims](./cache.md) \ No newline at end of file +Permify implements several cache mecnanisims in order to achieve low latency in scaled distributed systems. See more in the section [Cache Mechanisms](./cache.md) diff --git a/docs/versioned_docs/version-0.6.x/use-cases/_list.json b/docs/versioned_docs/version-0.6.x/use-cases/_list.json index 7b6e7fb11..853f367a9 100644 --- a/docs/versioned_docs/version-0.6.x/use-cases/_list.json +++ b/docs/versioned_docs/version-0.6.x/use-cases/_list.json @@ -2,7 +2,7 @@ { "id": 1, "title": "Role Based Access Control (RBAC)", - "description": "Want to implement role to your application ? Define an entity and manage your roles throught your applications.", + "description": "Want to implement role to your application ? Define an entity and manage your roles throughout your applications.", "link": "./simple-rbac" }, {