Merge branch 'master' into 'master'

Change future tense to present tense oauth2.md

See merge request gitlab-org/gitlab!60197

doc/api/oauth2.md

@@ -41,7 +41,7 @@ how all those flows work and pick the right one for your use case.
 Both **authorization code** (with or without PKCE) and **implicit grant** flows require `application` to be
 registered first via the `/profile/applications` page in your user's account.
 During registration, by enabling proper scopes, you can limit the range of
-resources which the `application` can access. Upon creation, you'll obtain the
+resources which the `application` can access. Upon creation, you obtain the
 `application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**.
 
 ### Prevent CSRF attacks
@@ -63,7 +63,7 @@ and the [OAuth 2.0 Threat Model RFC](https://tools.ietf.org/html/rfc6819#section
 These factors are particularly important when using the
 [Implicit grant flow](#implicit-grant-flow), where actual credentials are included in the `redirect_uri`.
 
-In the following sections you will find detailed instructions on how to obtain
+In the following sections you can find detailed instructions on how to obtain
 authorization with each flow.
 
 ### Authorization code with Proof Key for Code Exchange (PKCE)
@@ -213,12 +213,12 @@ To request the access token, you should redirect the user to the
 https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH&scope=REQUESTED_SCOPES
 ```
 
-This will ask the user to approve the applications access to their account
+This prompts the user to approve the applications access to their account
 based on the scopes specified in `REQUESTED_SCOPES` and then redirect back to
 the `REDIRECT_URI` you provided. The [scope parameter](https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-Scopes#requesting-particular-scopes)
    is a space separated list of scopes you want to have access to (e.g. `scope=read_user+profile`
 would request `read_user` and `profile` scopes). The redirect
-will include a fragment with `access_token` as well as token details in GET
+includes a fragment with `access_token` as well as token details in GET
 parameters, for example:
 
 ```plaintext
@@ -285,7 +285,7 @@ echo 'grant_type=password&username=<your_username>&password=<your_password>' > a
 curl --data "@auth.txt" --user client_id:client_secret --request POST "https://gitlab.example.com/oauth/token"
 ```
 
-Then, you'll receive the access token back in the response:
+Then, you receive a response containing the access token:
 
 ```json
 {
@@ -358,7 +358,7 @@ The fields `scopes` and `expires_in_seconds` are included in the response.
 These are aliases for `scope` and `expires_in` respectively, and have been included to
 prevent breaking changes introduced in [doorkeeper 5.0.2](https://github.com/doorkeeper-gem/doorkeeper/wiki/Migration-from-old-versions#from-4x-to-5x).
 
-Don't rely on these fields as they will be removed in a later release.
+Don't rely on these fields as they are slated for removal in a later release.
 
 ## OAuth2 tokens and GitLab registries
 

doc/architecture/blueprints/database_testing/index.md

@@ -79,7 +79,7 @@ Database Lab provides an API we can interact with to manage thin clones. In orde
 
 The short-term focus is on testing regular migrations (typically schema changes) and using the existing Database Lab instance from postgres.ai for it.
 
-In order to secure this process and meet compliance goals, the runner environment will be treated as a *production* environment and similarly locked down, monitored and audited. Only Database Maintainers will have access to the CI pipeline and its job output. Everyone else will only be able to see the results and statistics posted back on the merge request.
+In order to secure this process and meet compliance goals, the runner environment is treated as a *production* environment and similarly locked down, monitored and audited. Only Database Maintainers have access to the CI pipeline and its job output. Everyone else can only see the results and statistics posted back on the merge request.
 
 We implement a secured CI pipeline on <https://ops.gitlab.net> that adds the execution steps outlined above. The goal is to secure this pipeline in order to solve the following problem:
 
@@ -117,7 +117,7 @@ An alternative approach we have discussed and abandoned is to "scrub" and anonym
 - Anonymization is complex by nature - it is a hard problem to call a "scrubbed clone" actually safe to work with in public. Different data types may require different anonymization techniques (e.g. anonymizing sensitive information inside a JSON field) and only focusing on one attribute at a time does not guarantee that a dataset is fully anonymized (for example join attacks or using timestamps in conjunction to public profiles/projects to de-anonymize users by there activity).
 - Anonymization requires an additional process to keep track and update the set of attributes considered as sensitive, ongoing maintenance and security reviews every time the database schema changes.
 - Annotating data as "sensitive" is error prone, with the wrong anonymization approach used for a data type or one sensitive attribute accidentally not marked as such possibly leading to a data breach.
-- Scrubbing not only removes sensitive data, but also changes data distribution, which greatly affects performance of migrations and queries.
+- Scrubbing not only removes sensitive data, but it also changes data distribution, which greatly affects performance of migrations and queries.
 - Scrubbing heavily changes the database contents, potentially updating a lot of data, which leads to different data storage details (think MVC bloat), affecting performance of migrations and queries.
 
 ## Who