Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
f4d0e0d9c5
commit
13076511c6
|
@ -7,6 +7,8 @@
|
|||
= f.check_box :signup_enabled, class: 'form-check-input'
|
||||
= f.label :signup_enabled, class: 'form-check-label' do
|
||||
Sign-up enabled
|
||||
.form-text.text-muted
|
||||
= _("When enabled, any user visiting %{host} will be able to create an account.") % { host: "#{new_user_session_url(host: Gitlab.config.gitlab.host)}" }
|
||||
.form-group
|
||||
.form-check
|
||||
= f.check_box :send_user_confirmation_email, class: 'form-check-input'
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add documentation & helper text information regarding securing a GitLab instance
|
||||
merge_request: 18987
|
||||
author:
|
||||
type: changed
|
|
@ -98,7 +98,7 @@ Parameters:
|
|||
|
||||
## Delete group milestone
|
||||
|
||||
Only for user with developer access to the group.
|
||||
Only for users with Developer access to the group.
|
||||
|
||||
```
|
||||
DELETE /groups/:id/milestones/:milestone_id
|
||||
|
|
|
@ -96,7 +96,7 @@ Parameters:
|
|||
|
||||
## Delete project milestone
|
||||
|
||||
Only for user with developer access to the project.
|
||||
Only for users with Developer access to the project.
|
||||
|
||||
```
|
||||
DELETE /projects/:id/milestones/:milestone_id
|
||||
|
@ -137,7 +137,7 @@ Parameters:
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53861) in GitLab 11.9
|
||||
|
||||
Only for users with developer access to the group.
|
||||
Only for users with Developer access to the group.
|
||||
|
||||
```
|
||||
POST /projects/:id/milestones/:milestone_id/promote
|
||||
|
|
|
@ -29,7 +29,7 @@ the affected files to find someone.
|
|||
We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate
|
||||
some triaging policies. This is currently set up as a scheduled pipeline
|
||||
(`https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit`,
|
||||
must have at least developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
|
||||
must have at least Developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
|
||||
project.
|
||||
|
||||
## Labels
|
||||
|
|
|
@ -284,7 +284,7 @@ To update GitLab documentation:
|
|||
1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
|
||||
|
||||
TIP: **Tip:**
|
||||
Work in a fork if you do not have developer access to the GitLab project.
|
||||
Work in a fork if you do not have Developer access to the GitLab project.
|
||||
|
||||
Request help from the Technical Writing team if you:
|
||||
|
||||
|
|
|
@ -95,8 +95,8 @@ Each line represents a rule that was evaluated. There are a few things to note:
|
|||
|
||||
Here you can see that the first four rules were evaluated `false` for
|
||||
which user and subject. For example, you can see in the last line that
|
||||
the rule was activated because the user `root` had at reporter access to
|
||||
the `Project/4`.
|
||||
the rule was activated because the user `root` had Reporter access to
|
||||
`Project/4`.
|
||||
|
||||
When a policy is asked whether a particular ability is allowed
|
||||
(`policy.allowed?(:some_ability)`), it does not necessarily have to
|
||||
|
|
|
@ -15,15 +15,15 @@ a black-box testing framework for the API and the UI.
|
|||
|
||||
### Testing nightly builds
|
||||
|
||||
We run scheduled pipeline each night to test nightly builds created by Omnibus.
|
||||
We run scheduled pipelines each night to test nightly builds created by Omnibus.
|
||||
You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/nightly/pipelines`
|
||||
(need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
|
||||
|
||||
### Testing staging
|
||||
|
||||
We run scheduled pipeline each night to test staging.
|
||||
We run scheduled pipelines each night to test staging.
|
||||
You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/staging/pipelines`
|
||||
(need developer access permissions). Results are reported in the `#qa-staging` Slack channel.
|
||||
(need Developer access permissions). Results are reported in the `#qa-staging` Slack channel.
|
||||
|
||||
### Testing code in merge requests
|
||||
|
||||
|
|
|
@ -87,3 +87,7 @@ the above methods, provided the cloud provider supports it.
|
|||
- [Install GitLab on DigitalOcean](https://about.gitlab.com/blog/2016/04/27/getting-started-with-gitlab-and-digitalocean/): Install Omnibus GitLab on DigitalOcean.
|
||||
- _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md):
|
||||
Quickly test any version of GitLab on DigitalOcean using Docker Machine.
|
||||
|
||||
## Securing your GitLab installation
|
||||
|
||||
After completing your installation, check out our [recommended practices to secure your GitLab instance](../security/README.md#securing-your-gitlab-installation).
|
||||
|
|
|
@ -19,3 +19,9 @@ type: index
|
|||
- [Send email confirmation on sign-up](user_email_confirmation.md)
|
||||
- [Security of running jobs](https://docs.gitlab.com/runner/security/)
|
||||
- [Proxying images](asset_proxy.md)
|
||||
|
||||
## Securing your GitLab installation
|
||||
|
||||
To make sure your GitLab instance is safe and secure, please consider implementing
|
||||
[Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) to avoid
|
||||
malicious users creating accounts.
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
Before Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
After Width: | Height: | Size: 24 KiB |
|
@ -4,20 +4,42 @@ type: reference
|
|||
|
||||
# Sign-up restrictions **(CORE ONLY)**
|
||||
|
||||
You can use sign-up restrictions to require user email confirmation, as well as
|
||||
to blacklist or whitelist email addresses belonging to specific domains.
|
||||
You can use sign-up restrictions to:
|
||||
|
||||
>**Note**: These restrictions are only applied during sign-up. An admin is
|
||||
- Disable new signups.
|
||||
- Require user email confirmation.
|
||||
- Blacklist or whitelist email addresses belonging to specific domains.
|
||||
|
||||
NOTE: **Note:**
|
||||
These restrictions are only applied during sign-up from an external user. An admin is
|
||||
able to add a user through the admin panel with a disallowed domain. Also
|
||||
note that the users can change their email addresses after signup to
|
||||
disallowed domains.
|
||||
|
||||
## Disable new signups
|
||||
|
||||
When this setting is enabled, any user visiting your GitLab domain will be able to sign up for an account.
|
||||
|
||||
![Disable signups](img/disable_signup_v12_7.png)
|
||||
|
||||
You can restrict new users from signing up by themselves for an account in your instance by disabling this setting.
|
||||
|
||||
### Recommendations
|
||||
|
||||
For customers running public facing GitLab instances, we highly recommend that you
|
||||
consider disabling new signups if you do not expect public users to sign up for an
|
||||
account.
|
||||
|
||||
Alternatively, you could also consider setting up a
|
||||
[whitelist](#whitelist-email-domains) or [blacklist](#blacklist-email-domains) on
|
||||
email domains to prevent malicious users from creating accounts.
|
||||
|
||||
## Require email confirmation
|
||||
|
||||
You can send confirmation emails during sign-up and require that users confirm
|
||||
their email address before they are allowed to sign in.
|
||||
|
||||
![Email confirmation](img/email_confirmation.png)
|
||||
![Email confirmation](img/email_confirmation_v12_7.png)
|
||||
|
||||
## Minimum password length limit
|
||||
|
||||
|
|
|
@ -160,7 +160,7 @@ It is possible to generate diagrams and flowcharts from text in GitLab using [Me
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15107) in
|
||||
GitLab 10.3.
|
||||
|
||||
Visit the [official page](https://mermaidjs.github.io/) for more details.
|
||||
Visit the [official page](https://mermaidjs.github.io/) for more details. If you are new to using Mermaid or need help identifying issues in your Mermaid code, the [Mermaid Live Editor](https://mermaid-js.github.io/mermaid-live-editor/) is a helpful tool for creating and resolving issues within Mermaid diagrams.
|
||||
|
||||
In order to generate a diagram or flowchart, you should write your text inside the `mermaid` block:
|
||||
|
||||
|
|
|
@ -48,7 +48,7 @@ It is important to note that we have a few types of users:
|
|||
via another project's job.
|
||||
|
||||
- **External users**: CI jobs created by [external users](../permissions.md#external-users-core-only) will have
|
||||
access only to projects to which user has at least reporter access. This
|
||||
access only to projects to which the user has at least Reporter access. This
|
||||
rules out accessing all internal projects by default.
|
||||
|
||||
This allows us to make the CI and permission system more trustworthy.
|
||||
|
@ -114,7 +114,7 @@ docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com
|
|||
|
||||
Using single token had multiple security implications:
|
||||
|
||||
- The token would be readable to anyone who had developer access to a project
|
||||
- The token would be readable to anyone who had Developer access to a project
|
||||
that could run CI jobs, allowing the developer to register any specific
|
||||
Runner for that project.
|
||||
- The token would allow to access only the project's sources, forbidding from
|
||||
|
|
|
@ -22,7 +22,7 @@ There are two kinds of repository mirroring supported by GitLab:
|
|||
When the mirror repository is updated, all new branches, tags, and commits will be visible in the
|
||||
project's activity feed.
|
||||
|
||||
Users with at least [developer access](../../permissions.md) to the project can also force an
|
||||
Users with at least [Developer access](../../permissions.md) to the project can also force an
|
||||
immediate update, unless:
|
||||
|
||||
- The mirror is already being updated.
|
||||
|
|
|
@ -20423,6 +20423,9 @@ msgstr ""
|
|||
msgid "When a runner is locked, it cannot be assigned to other projects"
|
||||
msgstr ""
|
||||
|
||||
msgid "When enabled, any user visiting %{host} will be able to create an account."
|
||||
msgstr ""
|
||||
|
||||
msgid "When enabled, users cannot use GitLab until the terms have been accepted."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ describe('DiscussionNotesRepliesWrapper', () => {
|
|||
});
|
||||
|
||||
it('renders children directly', () => {
|
||||
expect(wrapper.html()).toEqual(`<ul>${TEST_CHILDREN}</ul>`);
|
||||
expect(wrapper.element.outerHTML).toEqual(`<ul>${TEST_CHILDREN}</ul>`);
|
||||
});
|
||||
});
|
||||
|
||||
|
@ -45,7 +45,7 @@ describe('DiscussionNotesRepliesWrapper', () => {
|
|||
const notes = wrapper.find('li.discussion-collapsible ul.notes');
|
||||
|
||||
expect(notes.exists()).toBe(true);
|
||||
expect(notes.html()).toEqual(`<ul class="notes">${TEST_CHILDREN}</ul>`);
|
||||
expect(notes.element.outerHTML).toEqual(`<ul class="notes">${TEST_CHILDREN}</ul>`);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
|
Loading…
Reference in New Issue