Add latest changes from gitlab-org/gitlab@master

4 files changed, 45 insertions, 4 deletions

diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index 1ee7f0665cd..4ed79e1f1d9 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -196,7 +196,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    for more details.
 
    NOTE:
-   If you need to use `0.0.0.0` or `*` as the listen_address, you also must add
+   If you need to use `0.0.0.0` or `*` as the `listen_address`, you also must add
    `127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
    `127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
 
diff --git a/doc/development/uploads/index.md b/doc/development/uploads/index.md
index 55c6650ed4a..b5509f5934e 100644
--- a/doc/development/uploads/index.md
+++ b/doc/development/uploads/index.md
@@ -87,6 +87,7 @@ this HTTP request is sent.
 
 - [Rails controller upload](#rails-controller-upload).
 - [Direct upload](#direct-upload).
+- [Workhorse assisted uploads](#workhorse-assisted-uploads).
 
 ### Rails controller upload
 
diff --git a/doc/user/application_security/dast/authentication.md b/doc/user/application_security/dast/authentication.md
index 31bbdca8122..3dfc0dbfe99 100644
--- a/doc/user/application_security/dast/authentication.md
+++ b/doc/user/application_security/dast/authentication.md
@@ -53,6 +53,7 @@ To run a DAST authenticated scan:
 
 | CI/CD variable                                 | Type          | Description                                                                                                                                                                                                                                                                          |
 |:-----------------------------------------------|:--------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `DAST_AUTH_COOKIES`                            | string        | Set to a comma-separated list of cookie names to specify which cookies are used for authentication.                                                                                                                                                                                  |
 | `DAST_AUTH_REPORT`                             | boolean       | Used in combination with exporting the `gl-dast-debug-auth-report.html` artifact to aid in debugging authentication issues.                                                                                                                                                          |
 | `DAST_AUTH_URL` <sup>1</sup>                   | URL           | The URL of the page containing the sign-in HTML form on the target website. `DAST_USERNAME` and `DAST_PASSWORD` are submitted with the login form to create an authenticated scan. Example: `https://login.example.com`.                                                             |
 | `DAST_AUTH_VERIFICATION_LOGIN_FORM`            | boolean       | Verifies successful authentication by checking for the absence of a login form once the login form has been submitted.                                                                                                                                                               |
@@ -314,6 +315,22 @@ by the authentication process.
 DAST considers cookies, local storage and session storage values set with sufficiently "random" values to be authentication tokens.
 For example, `sessionID=HVxzpS8GzMlPAc2e39uyIVzwACIuGe0H` would be viewed as an authentication token, while `ab_testing_group=A1` would not.
 
+The CI/CD variable `DAST_AUTH_COOKIES` can be used to specify the names of authentication cookies and bypass the randomness check used by DAST.
+Not only can this make the authentication process more robust, but it can also increase vulnerability check accuracy for checks that
+inspect authentication tokens.
+
+For example:
+
+```yaml
+include:
+  - template: DAST.gitlab-ci.yml
+
+dast:
+  variables:
+    DAST_WEBSITE: "https://example.com"
+    DAST_AUTH_COOKIES: "sessionID,refreshToken"
+```
+
 ## Known limitations
 
 - DAST cannot bypass a CAPTCHA if the authentication flow includes one. Please turn these off in the testing environment for the application being scanned.
@@ -333,11 +350,26 @@ Authentication failed because a home page should be displayed after login. Inste
 2022-11-16T13:43:02.000 INF AUTH  attempting to authenticate
 2022-11-16T13:43:02.000 INF AUTH  loading login page LoginURL=https://example.com/login
 2022-11-16T13:43:10.000 INF AUTH  multi-step authentication detected
-2022-11-16T13:43:20.000 INF AUTH  verifying if login attempt was successful true_when="no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
+2022-11-16T13:43:15.000 INF AUTH  verifying if user submit was successful true_when="HTTP status code < 400"
+2022-11-16T13:43:15.000 INF AUTH  requirement is satisfied, no login HTTP message detected want="HTTP status code < 400"
+2022-11-16T13:43:20.000 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
+2022-11-24T14:43:20.000 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 url=https://example.com/user/login?error=invalid%20credentials want="HTTP status code < 400"
 2022-11-16T13:43:21.000 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
 2022-11-16T13:43:21.000 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"
 ```
 
+### When authentication succeeds and the scan doesn't crawl authenticated pages
+
+Verify the captured authentication tokens are correct when a scan appears to authenticate and fails to crawl the authenticated pages of the application.
+Names of cookies and session tokens determined by DAST to be authentication tokens are written to the log. For example:
+
+```plaintext
+2022-11-24T14:42:31.492 INF AUTH  authentication token cookies names=["sessionID"]
+2022-11-24T14:42:31.492 INF AUTH  authentication token storage events keys=["token"]
+```
+
+See [authentication tokens](#authentication-tokens) for more information.
+
 ### Configure the authentication debug report
 
 An authentication report can be saved as a CI/CD job artifact to assist with understanding the cause of an authentication failure.
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 3ede5ebf4bb..39711d04c27 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -18,7 +18,7 @@ On self-managed GitLab, by default [migrating project items](#migrated-project-i
 this feature, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named
 `bulk_import_projects`. On GitLab.com, migration of both groups and projects is available.
 
-Users with the Owner role on a top-level group can use GitLab Migration to migrate the group to:
+Users with the Owner role on a top-level group can use GitLab Migration to migrate that top-level group to:
 
 - Another top-level group.
 - The subgroup of any existing top-level group.
@@ -28,7 +28,7 @@ Migrating groups using GitLab Migration is not the same as [migrating groups usi
 Importing and exporting groups using file exports requires you to export a group to a file and then import that file in
 another GitLab instance. Migrating groups using GitLab Migration automates this step.
 
-## Import your groups into GitLab
+## Import your groups and projects into GitLab
 
 When you migrate a group, you connect to your GitLab instance and then choose
 groups to import. Not all the data is migrated. See:
@@ -38,6 +38,14 @@ groups to import. Not all the data is migrated. See:
 
 Leave feedback about group migration in [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495).
 
+GitLab maps users and their contributions correctly provided:
+
+- Users already exists on the target GitLab instance.
+- Users have a public email on the source GitLab instance that matches their primary email on the target GitLab instance.
+
+When using an OmniAuth provider like SAML, GitLab and SAML accounts of users on GitLab must be linked. All users on the target GitLab instance must sign in and verify
+their account on the target GitLab instance. If the accounts are not linked, the user contribution mapping doesn't work correctly.
+
 NOTE:
 You might need to reconfigure your firewall to prevent blocking the connection on the self-managed
 instance.