Support Proxied SSL
In our infrastructure, the GitLab servers sit behind a load balancer that proxies the SSL.
Here is our current setup:
- Load Balancer Port 80 VIP (e.g. http://gitlab.mycompany.com)
- Redirects all traffic to Port 443 (https vip)
- Load Balancer Port 443 VIP (e.g. https://gitlab.mycompany.com)
- Proxies request to application server
- Request to application server is sent to port 80 of application server
- Load Balancer injects "X-FORWARDED-PROTO: HTTPS" into request to application server
- Load Balancer injects "X-FORWARDED-FOR: user agent IP" into request to application server
Unfortunately, if you specify an https address for external_url in gitlab.rb, the gitlab-ctl chef run will disable nginx listening on port 80 and turn on port 443 and SSL. I tried using the nginx['custom_nginx_config'] option in gitlab.rb to have nginx still listen on port 80, but when we ran into CSRF errors and a redirect loop when trying to login.
An ideal solution would allow a user deploying a GitLab Omnibus installation to manually set a gitlab_https or nginx['listen_https'] that would turn the functionality off. There's already https://gitlab.com/gitlab-org/omnibus-gitlab/commit/b5ec235ab191dfea4edf14b8a37f23a6d78bdd0a, which is also useful for the solution. There are at least three different ways to go:
- Require user to set gitlab_https and then automatically set nginx['listen_port'] to 80; however this seems like omnibus is thinking too much (which is why I'm submitting this issue in the first place)
- Require user to set gitlab_https and nginx['listen_port'] manually
- Require user to set nginx['listen_port'] to something other than 443, then automatically set gitlab_https to false
One thing of note is that gitlab_https (as determined by the gitlab.rb library) is also used in gitlab.yml to determine if https should be enabled: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/gitlab.yml.erb#L15 I don't know what this does, as I've set it to both false and true and have been able to push commits via HTTPS to GitLab.
We currently also experience a rather annoying back-and-forth, even in our existing 6.3.1 (non-omnibus) production installation every time gitlab-rails uses an absolute URL. Here's an example login flow:
- User visits http://gilab.mycompany.com
- Load Balancer redirects user to https://gitlab.mycompany.com
- If user is not logged in, GitLab redirects user to http://gitlab.mycompany.com/users/sign_in
- Load Balancer redirects user to https://gitlab.mycompany.com/users/sign_in
- User posts login to https://gitlab.mycompany.com/users/auth/ldap/callback
- GitLab redirects user to http://gitlab.mycompany.com
- Load Balancer redirects user to https://gitlab.mycompany.com
An ideal solution would also inform the gitlab-rails application that https is being proxied. If gitlab-rails can read written to consider X-FORWARDED-PROTO and respond accordingly, that would also work.