paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 40 Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Co-authored-by: Fredrik Adelöw <freben@gmail.com>
Signed-off-by: Aramis Sennyey <34432188+sennyeya@users.noreply.github.com>
This commit is contained in:
Aramis Sennyey
2024-01-29 14:34:41 -05:00
committed by GitHub
parent fe069efbe6
commit fd563915eb
2 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/permissions/concepts.md
+1 -1
View File
@@ -16,4 +16,4 @@ In many cases, a permission represents a user's interaction with another object.
See [Conditional decisions](../references/glossary.md#conditional-decisions).
A good example would be the catalog plugin's "has annotation" rule needs to know what annotation to look for on a given entity. The permission framework would respond to a request by the catalog plugin in this case with a condition decision. The catalog plugin would then need to correctly filter for entities matching the "has annotations" condition. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
A good example would be the catalog plugin's "has annotation" rule which needs to know what annotation to look for on a given entity. The permission framework would respond to a request by the catalog plugin in this case with a condition decision. The catalog plugin would then need to correctly filter for entities matching the "has annotations" condition. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
docs/references/glossary.md
+5 -5
View File
@@ -183,7 +183,7 @@ Refers to: OAuth 2.0, a standard protocol for authorization. See [oauth.net/2/](
## OpenID Connect
A layer on top of [OAuth](#oauth) which standardises authentication. See [en.wikipedia.org/wiki/OpenID_Connect](https://en.wikipedia.org/wiki/OpenID_Connect).
A layer on top of [OAuth](#oauth) which standardises authentication. See [the Wikipedia article](https://en.wikipedia.org/wiki/OpenID_Connect) for more details.
## OSS
@@ -195,7 +195,7 @@ A package in the Node.js ecosystem, often published to a [package registry](#pac
## Package Registry
A service that hosts packages. The most prominent example is [NPM](https://www.npmjs.com/).
A service that hosts [packages](#package). The most prominent example is [NPM](https://www.npmjs.com/).
## Package Role
@@ -247,7 +247,7 @@ An abstraction layer between a search engine and the [Backstage Search](#search)
## Refresh Token
A string that an [OAuth](#oauth) client can use to get a new access token.
A special token that an [OAuth](#oauth) client can use to get a new [access token](#access-token) when the latter expires.
https://oauth.net/2/refresh-tokens/
@@ -263,7 +263,7 @@ See [User Role](#User-Role).
## Scope
A string that describes a certain type of access that can be granted to a user using OAuth.
A string that describes a certain type of access that can be granted to a user using OAuth, usually in conjunction with [access tokens](#access-token).
## Search
@@ -307,4 +307,4 @@ A purpose for which a [user role](#User-Role) interacts with Backstage. Related
## User Role
A class of Backspace user for purposes of analyzing [use cases](#use-case). One of: evaluator; administrator; developer; integrator; and contributor.
A class of Backstage user for purposes of analyzing [use cases](#use-case). One of: evaluator; administrator; developer; integrator; and contributor.