147 lines
5.6 KiB
Plaintext
147 lines
5.6 KiB
Plaintext
---
|
|
summary: Support for proxy and load balancers
|
|
---
|
|
created: 2014-11-25 15:48:22.0
|
|
creator: tb0hdan
|
|
description: |-
|
|
As a Synapse user I would like to be able to place it behind proxy (e.g. nginx, haproxy) or load balancer (e.g. aws-elb) to take care of SSL termination and to provide application scalability.
|
|
|
|
This implies properly handling X-Forwarded-Proto handler and allowing
|
|
HTTP-only mode with Synapse.
|
|
id: '10704'
|
|
key: SYN-167
|
|
number: '167'
|
|
priority: '3'
|
|
project: '10000'
|
|
reporter: tb0hdan
|
|
resolution: '1'
|
|
resolutiondate: 2016-10-07 12:45:46.0
|
|
status: '5'
|
|
type: '2'
|
|
updated: 2016-10-07 12:45:46.0
|
|
votes: '0'
|
|
watches: '5'
|
|
workflowId: '10804'
|
|
---
|
|
actions:
|
|
- author: erikj
|
|
body: |-
|
|
There is already a --no-tls flag that will disable the HTTPS listeners and a --unsecure-port option to specify a HTTP listener, allowing you to run them behind an SSL terminator and load balancer.
|
|
|
|
We need still need to think about how this works with X-Forwarded- headers, including for request logging and IPs for the captcha.
|
|
created: 2014-11-25 16:02:18.0
|
|
id: '10833'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: erikj
|
|
updated: 2014-11-25 16:02:18.0
|
|
- author: kegan
|
|
body: IPs for the captcha already do handle X-Forwarded-For headers if that config option is set.
|
|
created: 2014-11-25 16:05:13.0
|
|
id: '10834'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: kegan
|
|
updated: 2014-11-25 16:05:13.0
|
|
- author: erikj
|
|
body: Hmm, true. Although we do still need to add configuration options for whitelisting IPs that are allowed to send HTTP traffic with X-Forwarded-For headers attached.
|
|
created: 2014-11-25 16:06:54.0
|
|
id: '10835'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: erikj
|
|
updated: 2014-11-25 16:06:54.0
|
|
- author: tb0hdan
|
|
body: |-
|
|
When running client as follows there's issue with media handling:
|
|
{code}
|
|
python -m synapse.app.homeserver -c homeserver.yaml --pid-file homeserver.pid --no-tls --unsecure-port 8008
|
|
{code}
|
|
|
|
{code}
|
|
https://somedomain.ddns.net:8448/_matrix/content/base64here.png
|
|
{code}
|
|
created: 2014-11-25 16:19:56.0
|
|
id: '10836'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: tb0hdan
|
|
updated: 2014-11-25 16:19:56.0
|
|
- author: erikj
|
|
body: |-
|
|
The only issue when I tried this was that I was using a self signed certificate, which meant that I had to manually open the image in another tab (in the web client) and accept the certificate. (This is a known annoyance we are hoping to fix soon.)
|
|
|
|
Alternatively, you can change the content repository location to point to the http address using --content-addr (e.g. http://somedomain.ddns.net:8080)
|
|
created: 2014-11-25 16:27:18.0
|
|
id: '10837'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: erikj
|
|
updated: 2014-11-25 16:27:18.0
|
|
- author: erikj
|
|
body: We should probably also make a how-to about running synapse behind load balancers :)
|
|
created: 2014-11-25 16:29:38.0
|
|
id: '10838'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: erikj
|
|
updated: 2014-11-25 16:29:38.0
|
|
- author: tb0hdan
|
|
body: |-
|
|
Running synapse using following command:
|
|
{code}
|
|
python -m synapse.app.homeserver -c homeserver.yaml --pid-file homeserver.pid --no-tls --unsecure-port 8008 --content-addr http://somedomain.ddns.net:8008
|
|
{code}
|
|
|
|
seems to solve wrong link issue for newly uploaded images only, old ones are still provided as 'https....'
|
|
|
|
Guess it would be nicer to have single switch for running behing proxy.
|
|
created: 2014-11-25 16:53:44.0
|
|
id: '10839'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: tb0hdan
|
|
updated: 2014-11-25 16:53:44.0
|
|
- author: matthew
|
|
body: We're about to fix the content repository problem - it's really embarrassing that historical URLs are hardcoded to the wrong address, and clearly we shouldn't be ever having to accept self-signed certificates in the browser. SYN-24 is the main issue tracking this.
|
|
created: 2014-11-25 16:58:10.0
|
|
id: '10841'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: matthew
|
|
updated: 2014-11-25 16:58:10.0
|
|
- author: matthew
|
|
body: |-
|
|
We have further problems here:
|
|
* If you want to put your federation API behind an HTTPS LB, connections from remote homeservers won't trust the LB's cert at all; they will try to grab the cert over HTTPS from your homeserver, and object if it doesn't match the one presented in the SSL handshake. The workaround for now is to copy your LB's cert over the top of your Synapse's self-signed one... and for now you also need to copy the private key too, so the SSL ctxt sets up right :((
|
|
|
|
So, to fix:
|
|
* Should remote servers trust officially signed X.509 certs, and ignore the out-of-band cert discovery process designed for self-signed ones?
|
|
* Alternatively, synapse shouldn't care if the private key is invalid if its SSL listener isn't actually being used
|
|
* We should have a way to disable synapse's SSL listener entirely (e.g. by deleting it from the config), if an HTTP LB is being used.
|
|
created: 2014-12-05 19:19:47.0
|
|
id: '10975'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: matthew
|
|
updated: 2014-12-05 19:19:47.0
|
|
- author: matthew
|
|
body: Also, we need a better mechanism than SRV records for discovering client-server API. well-known URIs would be a better bet. Plus we should probably support them for server-server API (although let them be trumped by SRV if people want to faff with SRV)
|
|
created: 2014-12-05 19:21:05.0
|
|
id: '10976'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: matthew
|
|
updated: 2014-12-05 19:21:05.0
|
|
- author: richvdh
|
|
body: |-
|
|
synapse works behind a proxy.
|
|
|
|
the other things here are different bugs.
|
|
created: 2016-10-07 12:45:46.0
|
|
id: '13174'
|
|
issue: '10704'
|
|
type: comment
|
|
updateauthor: richvdh
|
|
updated: 2016-10-07 12:45:46.0
|