Support operating behind a proxy which users access via SSL




7 years ago
6 years ago


(Reporter: Max Kanat-Alexander, Unassigned)





7 years ago
On and other places, the actual server that users are hitting is a load-balancing proxy. SSL negotiation happens between the user and the load-balancer. The load-balancer talks to Bugzilla via normal HTTP. This means that Bugzilla *thinks* it is being access via normal HTTP, when in fact the URL being used is an HTTPS URL.

The current solution that I have is to create a parameter, ssl_proxy, that makes Bugzilla set $ENV{'HTTPS'} to 'ON' if the accessing IP is in inbound_proxies.

Comment 1

7 years ago
I ran into an interesting problem while implementing this for a client--the proxy itself did heartbeat checks by doing "HEAD /" against the backend servers. (It probably should have been using testagent.cgi, but it wasn't.)  If this got "ssl redirected" and thus returned a 302, the proxy would think the servers were dead because they didn't return a 200.

Comment 2

7 years ago
Ah ha, nevermind, that was an error in the client's configuration--they didn't have the IPs that the heartbeats were coming from listed in inbound_proxies.


7 years ago
Target Milestone: Bugzilla 4.2 → Bugzilla 5.0

Comment 3

6 years ago
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.