enforce-ssl=true and multi vip support (bad redirect)

[Alvaro Uria]

Hi,

When enforce-ssl=true, VIP is used to force http into https.
https://github.com/openstack/charm-openstack-dashboard/blob/master/hooks/horizon_contexts.py#L219

I think %{SERVER_NAME} should be used (and UseCanonicalName enabled; default is Off), so that redirects go to the same "Host:" header used.
https://httpd.apache.org/docs/2.2/mod/core.html#usecanonicalname

When using multiple VIPs space-delimited, ssl_addr is "https://vip1 vip2:443/"
https://github.com/openstack/charm-openstack-dashboard/blob/master/templates/default#L4

Thank you!

[Billy Olsen (billy-olsen)]

This is more of an issue that the charm doesn't actually support multiple VIPs than it is that the redirect is off.

[Billy Olsen (billy-olsen)]

To clarify, the vip option for the openstack-dashboard does not reference that multiple VIPs can be supplied. Its quite misleading as for all the other charms serving http(s) endpoints, they do allow for multiple VIPs (one per network).

Other charms provide public, internal, and admin endpoints which are then registered within keystone. The openstack dashboard is never officially registered within keystone and therefore doesn't have the multiple VIPs.

So while there is a bad redirect with multiple vips, the charm doesn't actually support them.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/463850

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/463850
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=51b099c79e4fed72a013f89bb697137b1b794bf7
Submitter: Jenkins
Branch: master

commit 51b099c79e4fed72a013f89bb697137b1b794bf7
Author: Daniel Axtens <email address hidden>
Date: Thu May 11 04:41:19 2017 +1000

    Rework enforce_ssl to use host name, not address

    If enforce_ssl is set to true in openstack-dashboard, a user is
    redirected to the IP address of the server, not its hostname.

    This boils down to the template used to construct the site, which
    is always fed an IP address by horizon_context.py.

    Instead of using an IP address, use the result of resolve_address.

    (This is part of an odd quirk whereby the charm doesn't use the
    standard https tooling but does its own. A conversion to standard
    tooling would be required for a full fix to #1664954.)

    Closes-Bug: #1689882
    Related-Bug: #1664954
    Change-Id: I93365b75211e3c48d64ba8510898750dbc7b73cd
    Signed-off-by: Daniel Axtens <email address hidden>

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/17.02
Review: https://review.openstack.org/468255

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/468255
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=f4c8cadd4caa6a21f8511b3f5e4d9f1ab404f6cd
Submitter: Jenkins
Branch: stable/17.02

commit f4c8cadd4caa6a21f8511b3f5e4d9f1ab404f6cd
Author: Daniel Axtens <email address hidden>
Date: Thu May 11 04:41:19 2017 +1000

    Rework enforce_ssl to use host name, not address

    If enforce_ssl is set to true in openstack-dashboard, a user is
    redirected to the IP address of the server, not its hostname.

    This boils down to the template used to construct the site, which
    is always fed an IP address by horizon_context.py.

    Instead of using an IP address, use the result of resolve_address.

    (This is part of an odd quirk whereby the charm doesn't use the
    standard https tooling but does its own. A conversion to standard
    tooling would be required for a full fix to #1664954.)

    Closes-Bug: #1689882
    Related-Bug: #1664954
    Change-Id: I93365b75211e3c48d64ba8510898750dbc7b73cd
    Signed-off-by: Daniel Axtens <email address hidden>
    (cherry picked from commit 51b099c79e4fed72a013f89bb697137b1b794bf7)

[Nobuto Murata (nobuto)]

I have filed similar bugs:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1713198
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1710930

And a patch here:
https://review.openstack.org/#/c/498168/