delta/gitlab/gitlab-ce.git/spec/initializers, branch feature/github-edit-path

Give priority to environment variables

2016-08-03T14:48:48+00:00

If an environment variable exists for secret_key_base, use that -
always. But don't save it to secrets.yml.

Also ensure that we never write to secrets.yml if there's a non-blank
value there.

Store all secret keys in secrets.yml

2016-08-03T14:48:47+00:00

Move the last secret from .secret to config/secrets.yml, and delete
.secret if it exists.

Store OTP secret key in secrets.yml

2016-08-03T14:46:37+00:00

.secret stores the secret token used for both encrypting login cookies
and for encrypting stored OTP secrets. We can't rotate this, because
that would invalidate all existing OTP secrets.

If the secret token is present in the .secret file or an environment
variable, save it as otp_key_base in secrets.yml. Now .secret can be
rotated without invalidating OTP secrets.

If the secret token isn't present (initial setup), then just generate a
separate otp_key_base and save in secrets.yml.

Update the docs to reflect that secrets.yml needs to be retained past
upgrades, but .secret doesn't.

Ignore invalid IPs in X-Forwarded-For when trusted proxies are configured.

2016-07-31T19:36:11+00:00

Ignore invalid trusted proxies in X-Forwarded-For header

2016-07-24T04:06:19+00:00

Certain reverse proxies can send invalid IP addresses in the X-Forwarded-For header
For example, Apache can send (null).

Closes #20194

Skip repository storage path valitaions on test environment

2016-07-21T22:33:51+00:00

Storage path are not created until `TestEnv.init`, so we must skip
their validation on initialization.

Use Pathname to make the repository storage path validations more robust

2016-07-21T22:29:56+00:00

Enable Style/EmptyLines cop, remove redundant ones

2016-07-01T19:56:17+00:00

Merge branch 'rack-request-trusted-proxies' into 'master'

2016-06-30T15:37:16+00:00


Make Rack::Request use our trusted proxies when filtering IP addresses

## What does this MR do?

This allows us to control the trusted proxies while deployed in a private network.

## Are there points in the code the reviewer needs to double check?

If we want to limit what is impacted, we can do this specifically for the rack_attack request object.

## Why was this MR needed?

Normally Rack::Request will trust all private IPs as trusted proxies, which can cause problems if your users are connection on you network via private IP ranges.
    
Normally in a rails app this is handled by action_dispatch request, but rack_attack is specifically using the Rack::Request object instead.

## What are the relevant issue numbers?

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/17550

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [ ] ~~API support added~~
- Tests
  - [x] Added for this feature/bug
  - [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)


\cc @stanhu

See merge request !4958

Make Rack::Request use our trusted proxies when filtering IP addresses

2016-06-30T04:19:55+00:00

This allows us to control the trusted proxies while deployed in a private network. Normally Rack::Request will trust all private IPs as trusted proxies, which can caue problems if your users are connection on you network via private IP ranges.

Normally in a rails app this is handled by action_dispatch request, but rack_attack is specifically using the Rack::Request object instead.