User images and videos will get proxied through
the Camo server in order to keep malicious
sites from collecting the IP address of users.

Reuben Pereira authored 5 years ago and Mayra Cabrera committed 5 years ago

Add to the service and migration both.

Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758

vshushlin authored 5 years ago and Nick Thomas committed 5 years ago

- Set access level in before_validation hook
- Add post migration for updating existing project_features

This will make it possible to whitelist multiple IP addresses
(e.g. 192.168.0.1/24).

Patrick Bajao authored 5 years ago and Nick Thomas committed 5 years ago

In this commit, some methods that aren't being used
are removed from `Gitlab::Shell`. They are the ff:
- `#remove_keys_not_found_in_db`
- `#batch_read_key_ids`
- `#list_key_ids`

The corresponding methods in `Gitlab::Keys` have been
removed as well.

Used in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5782

Signed-off-by: Rémy Coutable <remy@rymai.me>

The ApplicationSetting model uses the CacheMarkdownField concern, which updates
the cached HTML when the field is updated in the database. However, in specs,
when we want to test conditions using ApplicationSetting, we stub it, because
this is accessed in different ways throughout the application.

This means that if a spec runs that caches one of the Markdown fields, and a
later spec uses `stub_application_setting` to set the raw value of that field,
the cached value was still the original one. We can work around this by ignoring
the Markdown cache in contexts where we're using `stub_application_setting`.

We could be smarter, and only do this on the Markdown fields of the model, but
this is probably fine.

Moving the check out of the general requests, makes sure we don't have
any slowdown in the regular requests.

To keep the process performing this checks small, the check is still
performed inside a unicorn. But that is called from a process running
on the same server.

Because the checks are now done outside normal request, we can have a
simpler failure strategy:

The check is now performed in the background every
`circuitbreaker_check_interval`. Failures are logged in redis. The
failures are reset when the check succeeds. Per check we will try
`circuitbreaker_access_retries` times within
`circuitbreaker_storage_timeout` seconds.

When the number of failures exceeds
`circuitbreaker_failure_count_threshold`, we will block access to the
storage.

After `failure_reset_time` of no checks, we will clear the stored
failures. This could happen when the process that performs the checks
is not running.

Instead of from the configuration file

This allows testing every storage attempt after a failure. Which could
be useful for tests

The implementation now simply rely on the
`performance_bar_allowed_group_id` Application Setting.

Signed-off-by: Rémy Coutable <remy@rymai.me>

A `performance_team` Flipper group has been created. By default this
group is nil but this can be customized in `gitlab.yml` via the
performance_bar.allowed_group setting.

Signed-off-by: Rémy Coutable <remy@rymai.me>

This commit lets a user bypass the automatic signin on the login form,
in order to login with a technical (admin, etc) account

Closes #3786

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

These specs also failed when run by themselves before this change, so
we've likely got some kind of cross-test contamination going on.