An empty file in one of the instrumented directories will cause the app
to fail to start when metrics are enabled. Metrics aren't enabled by
default in development or test.
We could handle the empty file case explicitly, but a file could still
not define the constant it is expected to, so instead run the
initializer manually in a spec and check that it succeeds.
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.
.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.
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
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.
Each test reloads the trusted_proxies initializer, which in turn will set Rails.application.config.action_dispatch.trusted_proxies to something new. This will leak into the other tests, but the middleware that it is used in has already been loaded for the whole test suite, so it should have no impact.
