WAZO-1760 add reverse proxy

[sboily]

Jira-Issue: https://wazo-dev.atlassian.net/browse/WAZO-1759

Jira-Issue: https://wazo-dev.atlassian.net/browse/WAZO-1760

[wazo-zuul]

Build succeeded.

• tox-linters : SUCCESS in 4m 47s
• wazo-tox-py37 : SUCCESS in 5m 07s
• wazo-tox-integration : SUCCESS in 24m 16s
• debian-packaging : SUCCESS in 6m 20s

[fblackburn1]

URL template need to be updated too to support prefix. Otherwise I don't think this config is usable.
If need to be done, probably that @bloom1 can complete this ticket, but to be confirmed

[sboily]

Not sure to understand your comment, we made test with @bloom1 yesterday and it works.

[pc-m]

URL template need to be updated too to support prefix. Otherwise I don't think this config is usable.
If need to be done, probably that @bloom1 can complete this ticket, but to be confirmed

I think the reverse proxy is useful even if it's not used by phones right now. The phone control API needs to be available to users. I think using the reverse proxy from phones is a different story and can be done later if needed.

[sboily]

URL template need to be updated too to support prefix. Otherwise I don't think this config is usable.
If need to be done, probably that @bloom1 can complete this ticket, but to be confirmed

I think the reverse proxy is useful even if it's not used by phones right now. The phone control API needs to be available to users. I think using the reverse proxy from phones is a different story and can be done later if needed.

Nope we need it for phones who are external to the network. With the DND feature we need to have a reverse proxy.

[fblackburn1]

Not sure to understand your comment, we made test with @bloom1 yesterday and it works.

Since your ticket is not linked to anything and request anyone. I only wanted to notify @bloom1 about it. He probably knows what I'm talking about

[sboily]

Yep it's linked to the DND feature i checked with @bloom1 yesterday.

skipped comments

[sduthil]

The URL templates in wazo-phoned do not need updating: they use request.base_url, which already contains the URL prefix that the client used.
The URL templates in wazo-provd are another story...

[wazo-zuul]

Build failed.

• tox-linters : SUCCESS in 7m 47s
• wazo-tox-py37 : SUCCESS in 7m 59s
• wazo-tox-integration : FAILURE in 25m 18s
• debian-packaging : SUCCESS in 8m 54s

[sduthil]

There is a security problem with this PR though:

• when receiving a request from nginx, we want wazo-phoned to interpret the X-Forwarded-For header to allow authorized IP only, and not accept every nginx request because they come from nginx at 127.0.0.1
• when receiving a request from the outside we DO NOT want wazo-phoned to interpret the X-Forwarded-For header, because any attacker could set this header to 127.0.0.1 on his incoming request to bypass IP-based authorization. There is an explicit test for this case, the one that failed on zuul.

[sduthil]

The correct solution for the security problem would be to make wazo-phoned listen only on 127.0.0.1 and never receive an outside request directly. But wazo-provd needs to be updated first to do that.

An intermediate solution would be to make nginx listen also on ports 9498,9499 and redirect requests to wazo-phoned on another port. That way:

• incoming outside requests are all handled by nginx and the X-Forwarded-For is always written by nginx
• phone requests to wazo.example.com:9498 are still valid and go through nginx

[fblackburn1]

The URL templates in wazo-phoned do not need updating: they use request.base_url, which already contains the URL prefix that the client used.

I'm not sure I understand which URL template inside wazo-phoned that refers to itself you talk?

The URL templates in wazo-provd are another story...

That's what I don't understand: Why adding reverse proxy on wazo-phoned if wazo-provd cannot use it? If we don't change wazo-provd at the same time, then we add a dead code. Or maybe it's for really specific scenario like manual configuration? (JIRA ticket need to be more specific about goal of this change)

An intermediate solution would be to make nginx listen also on ports 9498,9499 and redirect requests to wazo-phoned on another port.

Alternative, you can add a configuration key to configure phoned to only accept X-Forward-For from a specific IP (nginx)

[sduthil]

The URL templates in wazo-phoned do not need updating: they use request.base_url, which already contains the URL prefix that the client used.

I'm not sure I understand which URL template inside wazo-phoned that refers to itself you talk?

For example this template: https://github.com/wazo-platform/wazo-phoned/blob/master/wazo_phoned/plugins/aastra/templates/aastra_input.jinja

The URL templates in wazo-provd are another story...

That's what I don't understand: Why adding reverse proxy on wazo-phoned if wazo-provd cannot use it? If we don't change wazo-provd at the same time, then we add a dead code. Or maybe it's for really specific scenario like manual configuration? (JIRA ticket need to be more specific about goal of this change)

I'm not sure. @bloom1 could you explain us? Is it related to DND synchronization? Is it simpler to do the provisioning plugin update after this is merged?

An intermediate solution would be to make nginx listen also on ports 9498,9499 and redirect requests to wazo-phoned on another port.

Alternative, you can add a configuration key to configure phoned to only accept X-Forward-For from a specific IP (nginx)

I don't see how to implement that behavior... Subclass ProxyFix from werkzeug?

[fblackburn1]

For example this template: https://github.com/wazo-platform/wazo-phoned/blob/master/wazo_phoned/plugins/aastra/templates/aastra_input.jinja

ooh yeah, you're right, thanks

I don't see how to implement that behavior... Subclass ProxyFix from werkzeug?

yes or something similar to: https://github.com/wazo-platform/xivo-lib-python/blob/master/xivo/http_helpers.py#L22