Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updated copy/paste issues in github quickstart #207

Merged
merged 1 commit into from
Nov 13, 2024
Merged

updated copy/paste issues in github quickstart #207

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/quickstarts/github/overview.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,10 +9,10 @@ description: GitHub Quickstart overview page
The GitHub scenario is an example of how to implement an authorization policy using a hierarchical, nested relationship-based access control (ReBAC) model.

The GitHub Quickstart includes:
* A domain model for GitHub, including `folder` and `doc` object types, `owner`, `editor`, and `viewer` relationships, and `can_read`, `can_write`, `can_share`, and `can_delete` permissions.
* A domain model for GitHub, including `organization`, `team`, and `repo` object types, `owner`, `admin`, `maintainer`, `writer`, `triager`, and `reader` relationships, and `can_read`, `can_triage`, `can_write`, `can_maintain`, `can_delete`, and `can_administer` permissions.
* A policy instance called `github` which uses a boilerplate authorization policy called `policy-rebac`. This policy simply uses the underlying relationships to determine access.
* A connection to the **Citadel Demo IDP**, which contains five demo users based on the Rick & Morty cartoon.
* Sample *resources*, including folders such as `Rick's Home Folder` and `Morty's Shared Folder`, and documents such as `Grocery list` and `Rick's inventions`. Rick & Morty have `owner`, `writer`, and `reader` *relationships* to these resources, demonstrating a relationship-based (ReBAC) model.
* Sample *resources*, including Organizations such as `citadel` `smiths`, and Repos such as `citadel.missions` and `smiths.budget`. Rick & Morty have `owner`, `writer`, and `reader` *relationships* to these resources, demonstrating a relationship-based (ReBAC) model.
* A back-end API that uses the `github` policy for authorization, implemented in several languages.
* An interactive tutorial which helps construct `curl` requests to test the back-end API.

Expand Down
2 changes: 1 addition & 1 deletion docs/quickstarts/github/use-the-evaluator.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ The table below explains the selection fields.

Now let's check a few different scenarios using the Evalator. First, a few important things to note about Rick and Morty:

* Both Rick and Morty are a `repo_admin` of the `citadel` organization. This means both of them have the `can_read`, `can_triate`, `can_write`, `can_maintain`, `can_delete`, and `can_administer` permissions on every `repo` for which the `citadel` organization is the `owner`. This includes the `citadel.missions` repo.
* Both Rick and Morty are a `repo_admin` of the `citadel` organization. This means both of them have the `can_read`, `can_triage`, `can_write`, `can_maintain`, `can_delete`, and `can_administer` permissions on every `repo` for which the `citadel` organization is the `owner`. This includes the `citadel.missions` repo.
* Morty is a `repo_reader` of the `smiths` organization. This means he only has the `can_read` permission on the organization and on any `repo` that is owned by the `smiths` organization, which includes the `smiths.budget` repo.

### Scenario 1 - can Morty administer the `smiths.budget` repo?
Expand Down