)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"e56a5042b65b7c66dbe432f70860c99eb977f606","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"98e65e1a_d48460ff","updated":"2024-06-04 17:19:09.000000000","message":"Ok, while I agree this logic is broken now, but the patch does not cover all use-cases still.\n\nSo if you define `keystone_backend_ssl: True`, which will cover HAProxy-\u003eApache connection with TLS, but keeping `haproxy_ssl_all_vips: False` - you\u0027ll get vice versa situation:\n```\n# curl http://172.29.236.101:5000\n{\"versions\": {\"values\": [{\"id\": \"v3.14\", \"status\": \"stable\", \"updated\": \"2020-04-07T00:00:00Z\", \"links\": [{\"rel\": \"self\", \"href\": \"https://172.29.236.101:5000/v3/\"}], \"media-types\": [{\"base\": \"application/json\", \"type\": \"application/vnd.openstack.identity-v3+json\"}]}]}}\n```","commit_id":"215e1b367778b9622b3a7ba23f8c3120fe56c85f"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"b8d2bfac5349eb5f52de5c5c5ae594f6432533f5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cd751913_517617cc","in_reply_to":"98e65e1a_d48460ff","updated":"2024-06-04 17:34:09.000000000","message":"But probably it\u0027s worth covering separately, as X-Forwarded-Proto makes no difference here, as it\u0027s Apache already knowing it\u0027s HTTPS. So let\u0027s leave that alone I guess for now... I\u0027d guess that `keystone_backend_ssl` should be used together with `haproxy_ssl_all_vips` anyway.","commit_id":"215e1b367778b9622b3a7ba23f8c3120fe56c85f"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"3e02db70f292dd65ac6bb03fa300be6cb03a5a21","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"c4d630a2_21bf9ecc","updated":"2024-07-05 09:35:40.000000000","message":"Hey! Do you think we should do same removal for Horizon as well?\nhttps://opendev.org/openstack/openstack-ansible-os_horizon/src/branch/master/templates/openstack_dashboard.conf.j2#L45-L49","commit_id":"e8d0f0db5f623f3a2ebbacca6b237f16f7d27202"},{"author":{"_account_id":14552,"name":"Bjoern Teipel","email":"bjoern.teipel@rackspace.com","username":"bjoern"},"change_message_id":"3698b26544bb357dd5147883ef5d46e542a16b3c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"65be0f0c_fcf56aaf","in_reply_to":"1dbf2688_bec5caa8","updated":"2024-07-08 14:58:46.000000000","message":"NVM just saw it was already conditional to horizon_enable_ssl so we should keep that as it was always configured to redirect to SSL on port 80","commit_id":"e8d0f0db5f623f3a2ebbacca6b237f16f7d27202"},{"author":{"_account_id":14552,"name":"Bjoern Teipel","email":"bjoern.teipel@rackspace.com","username":"bjoern"},"change_message_id":"ac4e9f7c178dfdcb1f109555fcf0569db1e88478","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"1dbf2688_bec5caa8","in_reply_to":"c4d630a2_21bf9ecc","updated":"2024-07-08 14:40:41.000000000","message":"For consistency we should, requests to port 80 always redirected to 443 since horizon always ran on SSL. So I would say we hard code the protocol header there or we change it to use horizon_enable_ssl, what do you think?","commit_id":"e8d0f0db5f623f3a2ebbacca6b237f16f7d27202"}],"templates/keystone-httpd.conf.j2":[{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"b8d2bfac5349eb5f52de5c5c5ae594f6432533f5","unresolved":true,"context_lines":[{"line_number":20,"context_line":"    {% endif -%}"},{"line_number":21,"context_line":"    Header set X-Frame-Options \"{{ keystone_x_frame_options | default (\u0027DENY\u0027) }}\""},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"    {% if (keystone_external_ssl | bool) %}"},{"line_number":24,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":25,"context_line":"    {% else %}"},{"line_number":26,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"http\""}],"source_content_type":"text/x-jinja2","patch_set":1,"id":"c4192955_784222b4","side":"PARENT","line":23,"range":{"start_line":23,"start_character":11,"end_line":23,"end_character":32},"updated":"2024-06-04 17:34:09.000000000","message":"Actually, it\u0027s the only place where `keystone_external_ssl` is used, so makes sense to drop the variable at all and issue a release note stating it\u0027s no longer in use.","commit_id":"4fa9f4f675d7159bdbafc18b4dd210a69de4af7e"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"b9c7c8ba4156ad1942590c2f2571a3b5613f380f","unresolved":false,"context_lines":[{"line_number":20,"context_line":"    {% endif -%}"},{"line_number":21,"context_line":"    Header set X-Frame-Options \"{{ keystone_x_frame_options | default (\u0027DENY\u0027) }}\""},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"    {% if (keystone_external_ssl | bool) %}"},{"line_number":24,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":25,"context_line":"    {% else %}"},{"line_number":26,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"http\""}],"source_content_type":"text/x-jinja2","patch_set":1,"id":"0553b90a_5ec840fb","side":"PARENT","line":23,"range":{"start_line":23,"start_character":11,"end_line":23,"end_character":32},"in_reply_to":"072b1b61_eefb9bf3","updated":"2024-06-04 19:20:51.000000000","message":"as of today you pretty much never will have internaluri_secure. as certificates for covering internal endpoints are signed with internal root CA that is trusted by systems.\n\nalso, quite some amount of deployments have tls end-to-end already. we were also considering flapping the default to have tls all the way.\n\nthough I agree that having haproxy -\u003e apache covered with tls and client -\u003e haproxy is unlikely, usually it\u0027s either default or all is tls.","commit_id":"4fa9f4f675d7159bdbafc18b4dd210a69de4af7e"},{"author":{"_account_id":14552,"name":"Bjoern Teipel","email":"bjoern.teipel@rackspace.com","username":"bjoern"},"change_message_id":"5010b32483ad21587c27141761aba42a3224e798","unresolved":false,"context_lines":[{"line_number":20,"context_line":"    {% endif -%}"},{"line_number":21,"context_line":"    Header set X-Frame-Options \"{{ keystone_x_frame_options | default (\u0027DENY\u0027) }}\""},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"    {% if (keystone_external_ssl | bool) %}"},{"line_number":24,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":25,"context_line":"    {% else %}"},{"line_number":26,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"http\""}],"source_content_type":"text/x-jinja2","patch_set":1,"id":"072b1b61_eefb9bf3","side":"PARENT","line":23,"range":{"start_line":23,"start_character":11,"end_line":23,"end_character":32},"in_reply_to":"c4192955_784222b4","updated":"2024-06-04 18:22:53.000000000","message":"Done","commit_id":"4fa9f4f675d7159bdbafc18b4dd210a69de4af7e"},{"author":{"_account_id":14552,"name":"Bjoern Teipel","email":"bjoern.teipel@rackspace.com","username":"bjoern"},"change_message_id":"01b4008f0ab2149e4f25f8de3b9e69865f437868","unresolved":false,"context_lines":[{"line_number":20,"context_line":"    {% endif -%}"},{"line_number":21,"context_line":"    Header set X-Frame-Options \"{{ keystone_x_frame_options | default (\u0027DENY\u0027) }}\""},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"    {% if (keystone_external_ssl | bool) %}"},{"line_number":24,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":25,"context_line":"    {% else %}"},{"line_number":26,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"http\""}],"source_content_type":"text/x-jinja2","patch_set":1,"id":"485c706a_763f9ec4","side":"PARENT","line":23,"range":{"start_line":23,"start_character":11,"end_line":23,"end_character":32},"in_reply_to":"c4192955_784222b4","updated":"2024-06-04 18:22:29.000000000","message":"That\u0027s fine I removed it and added a note. As most deployments are HTTP internally we should tender to those and for a end to end SSL then the x-forwarded-for header will be added (ie internaluri_secure enabled)","commit_id":"4fa9f4f675d7159bdbafc18b4dd210a69de4af7e"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"b9c7c8ba4156ad1942590c2f2571a3b5613f380f","unresolved":true,"context_lines":[{"line_number":16,"context_line":"    Header set X-XSS-Protection \"1; mode\u003dblock\""},{"line_number":17,"context_line":"    Header set Content-Security-Policy \"default-src \u0027self\u0027 https: wss:;\""},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"    {% if keystone_service_internaluri_insecure | bool %}"},{"line_number":20,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":21,"context_line":"    {% endif %}"},{"line_number":22,"context_line":""}],"source_content_type":"text/x-jinja2","patch_set":2,"id":"f08c4730_fd40a637","line":19,"range":{"start_line":19,"start_character":0,"end_line":19,"end_character":57},"updated":"2024-06-04 19:20:51.000000000","message":"sorry, that condition does not make much sense to me, as this is hardly ever a case, as internal certificates will most likely will be trusted by system due to integrating PKI role.\n\nAnd you\u0027re right overall, that loadbalancer in front should be tackling that. So I think it\u0027s fine to drop that overall.\n\nI haven\u0027t found any inconsistencies, unless Apache is covered with TLS, but then X-Forwarded-Proto is not reflected at all anyway.","commit_id":"38191b5246fd12d4413eaf9fc3136713f375021d"},{"author":{"_account_id":14552,"name":"Bjoern Teipel","email":"bjoern.teipel@rackspace.com","username":"bjoern"},"change_message_id":"ce76bf9e4272597f7b779150a8b1a8abfb2995f7","unresolved":false,"context_lines":[{"line_number":16,"context_line":"    Header set X-XSS-Protection \"1; mode\u003dblock\""},{"line_number":17,"context_line":"    Header set Content-Security-Policy \"default-src \u0027self\u0027 https: wss:;\""},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"    {% if keystone_service_internaluri_insecure | bool %}"},{"line_number":20,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":21,"context_line":"    {% endif %}"},{"line_number":22,"context_line":""}],"source_content_type":"text/x-jinja2","patch_set":2,"id":"2b2d9723_fd009153","line":19,"range":{"start_line":19,"start_character":0,"end_line":19,"end_character":57},"in_reply_to":"cda5b32b_3b28fcb3","updated":"2024-06-20 18:10:23.000000000","message":"Done","commit_id":"38191b5246fd12d4413eaf9fc3136713f375021d"},{"author":{"_account_id":14552,"name":"Bjoern Teipel","email":"bjoern.teipel@rackspace.com","username":"bjoern"},"change_message_id":"43c9efefadeb8488470230870ff3bcfc187125be","unresolved":true,"context_lines":[{"line_number":16,"context_line":"    Header set X-XSS-Protection \"1; mode\u003dblock\""},{"line_number":17,"context_line":"    Header set Content-Security-Policy \"default-src \u0027self\u0027 https: wss:;\""},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"    {% if keystone_service_internaluri_insecure | bool %}"},{"line_number":20,"context_line":"    RequestHeader set {{ keystone_secure_proxy_ssl_header }} \"https\""},{"line_number":21,"context_line":"    {% endif %}"},{"line_number":22,"context_line":""}],"source_content_type":"text/x-jinja2","patch_set":2,"id":"cda5b32b_3b28fcb3","line":19,"range":{"start_line":19,"start_character":0,"end_line":19,"end_character":57},"in_reply_to":"f08c4730_fd40a637","updated":"2024-06-20 18:09:59.000000000","message":"I fixed the commit message to match the commit intent","commit_id":"38191b5246fd12d4413eaf9fc3136713f375021d"}]}