01203e7188
The change in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24199 caused requests coming from a load balancer to arrive as 127.0.0.1 instead of the actual IP. `Rack::Request#ip` behaves slightly differently different than `ActionDispatch::Request#remote_ip`: the former will return the first X-Forwarded-For IP if all of the IPs are trusted proxies, while the second one filters out all proxies and falls back to REMOTE_ADDR, which is 127.0.0.1. For now, we can revert back to using `Rack::Request` because these middlewares don't manipulate parameters. The actual fix problem involves fixing Rails: https://github.com/rails/rails/issues/28436. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58573
29 lines
696 B
Ruby
29 lines
696 B
Ruby
# frozen_string_literal: true
|
|
|
|
module Gitlab
|
|
class RequestContext
|
|
class << self
|
|
def client_ip
|
|
Gitlab::SafeRequestStore[:client_ip]
|
|
end
|
|
end
|
|
|
|
def initialize(app)
|
|
@app = app
|
|
end
|
|
|
|
def call(env)
|
|
# We should be using ActionDispatch::Request instead of
|
|
# Rack::Request to be consistent with Rails, but due to a Rails
|
|
# bug described in
|
|
# https://gitlab.com/gitlab-org/gitlab-ce/issues/58573#note_149799010
|
|
# hosts behind a load balancer will only see 127.0.0.1 for the
|
|
# load balancer's IP.
|
|
req = Rack::Request.new(env)
|
|
|
|
Gitlab::SafeRequestStore[:client_ip] = req.ip
|
|
|
|
@app.call(env)
|
|
end
|
|
end
|
|
end
|