This commit fixes a problem where parent Failovers where not showing (subset children were fine).
Seems to have been introduced with a move/glimmer upgrade here #9154 so I'm adding a 1.9.x backport.
Some users are defining routing configurations that do not have associated services. This commit surfaces these configs in the topology visualization. Also fixes a minor internal bug with non-transparent proxy upstream/downstream references.
During #9617 we added a list view only for AuthMethods, but not a detail view. We did add the Adapter/Serializer that collected/reshaped data for a detail view.
The test for this serializer was skipped here, but I'm not sure why.
We then added #9845 which began to use this AuthMethod Serializer, but we didn't go back to finish up the skipped test here either.
This PR unskips this test and finishes off the test correctly.
This commit fixes 2 problems with our OIDC flow in the UI, the first is straightforwards, the second is relatively more in depth:
1: A typo (1.10.1 only)
During #10503 we injected our settings service into the our oidc-provider service, there are some comments in the PR as to the whys and wherefores for this change (https://github.com/hashicorp/consul/pull/10503/files#diff-aa2ffda6d0a966ba631c079fa3a5f60a2a1bdc7eed5b3a98ee7b5b682f1cb4c3R28)
Fixing the typo so it was no longer looking for an unknown service (repository/settings > settings)
fixed this.
2: URL encoding (1.9.x, 1.10.x)
TL;DR: /oidc/authorize/provider/with/slashes/code/with/slashes/status/with/slashes should be /oidc/authorize/provider%2Fwith%2Fslashes/code%2Fwith%2Fslashes/status%2Fwith%2Fslashes
When we receive our authorization response back from the OIDC 3rd party, we POST the code and status data from that response back to consul via acallback as part of the OIDC flow. From what I remember back when this feature was originally added, the method is a POST request to avoid folks putting secret-like things into API requests/URLs/query params that are more likely to be visible to the human eye, and POSTing is expected behaviour.
Additionally, in the UI we identify all external resources using unique resource identifiers. Our OIDC flow uses these resources and their identifiers to perform the OIDC flow using a declarative state machine. If any information in these identifiers uses non-URL-safe characters then these characters require URL encoding and we added a helper a while back to specifically help us to do this once we started using this for things that required URL encoding.
The final fix here make sure that we URL encode code and status before using them with one of our unique resource identifiers, just like we do with the majority of other places where we use these identifiers.
It can only work if there is a running service instance in the local DC,
so this is a bit misleading, since failover and redirects are typically
used when there is not an instance in the local DC.
It can only work if there is a running service instance in the local DC,
so this is a bit misleading, since failover and redirects are typically
used when there is not an instance in the local DC.
Add the list of common Connect CA configuration options to the
provider-specific CA docs.
Previously these options were only documented under the agent
configuration options. This change makes it so that all supported CA
provider configuration options are available from a single location.
Co-authored-by: Daniel Nephin <dnephin@hashicorp.com>
Add the list of common Connect CA configuration options to the
provider-specific CA docs.
Previously these options were only documented under the agent
configuration options. This change makes it so that all supported CA
provider configuration options are available from a single location.
Co-authored-by: Daniel Nephin <dnephin@hashicorp.com>
The current suggests the option expects a string of either "enabled" or "disabled" but this results in an error `'acl.enable_key_list_policy' expected type 'bool', got unconvertible type 'string', value: 'enabled'`. Setting to a boolean value resolves this, also had a quick look at the code (d2b58cd0d6/agent/config/runtime.go (L109)) and it suggests this too
The current suggests the option expects a string of either "enabled" or "disabled" but this results in an error `'acl.enable_key_list_policy' expected type 'bool', got unconvertible type 'string', value: 'enabled'`. Setting to a boolean value resolves this, also had a quick look at the code (d2b58cd0d6/agent/config/runtime.go (L109)) and it suggests this too
Add a section to the Connect Security page which highlights the risks
of exposing Envoy's administration interface outside of localhost.
Resolves#5692
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
Co-authored-by: Kent 'picat' Gruber <kent@hashicorp.com>
Add a section to the Connect Security page which highlights the risks
of exposing Envoy's administration interface outside of localhost.
Resolves#5692
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
Co-authored-by: Kent 'picat' Gruber <kent@hashicorp.com>
Add section for tagged addresses on service definition documentation.
Resolves#6989
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
Add section for tagged addresses on service definition documentation.
Resolves#6989
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
Clarify the function of `-address` flag when instantiating an ingress
gateway.
Resolves#9849
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
trujillo-adam