Page MenuHomePhabricator

Fix protocol serve detection for clustered repositories that terminate HTTPS
ClosedPublic

Authored by epriestley on May 5 2016, 11:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 28, 3:23 AM
Unknown Object (File)
Thu, Nov 21, 9:45 PM
Unknown Object (File)
Nov 18 2024, 3:33 PM
Unknown Object (File)
Nov 16 2024, 4:14 AM
Unknown Object (File)
Nov 14 2024, 3:29 AM
Unknown Object (File)
Nov 10 2024, 4:01 AM
Unknown Object (File)
Nov 6 2024, 9:13 AM
Unknown Object (File)
Oct 24 2024, 5:09 PM
Subscribers
None

Details

Summary

Ref T10927. Pretty sure the issue is:

  • User makes an HTTPS request.
  • Load balancer terminates it, but with an X-Forwarded-Proto header.
  • secure001 (or whatever; acting as web host) proxies it to secure002 (or whatever; acting as a repository host). This connection is plain HTTP.
  • Since this proxied connection is plain HTTP, we check if the repository can serve over "http", but it can't: only "https". So we fail incorrectly, even though the original user request was HTTPS.

In the long run we should probably forward the X-Forwarded-Proto header, but that has some weird implications and it's broadly fine to allow either protocol to serve as long as the other one is active: configuration like security.require-https is already stronger than these settings.

Test Plan

This is likely only observable in production, but normal cloning still works locally.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Fix protocol serve detection for clustered repositories that terminate HTTPS.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad edited edge metadata.
This revision is now accepted and ready to land.May 5 2016, 11:23 PM
This revision was automatically updated to reflect the committed changes.