Open makkes opened 1 year ago
Yes, right now there is an implicit and probably undoc'd behaviour where all config should specified in either but not both of:
If secret is found, everything specified on the cli will be ignored.
Solutions:
If you asked me I would ditch all the OIDC-related CLI flags, especially the client secret one as we likely don't want to encourage our users to have secrets lurking in Deployment resources (that usually aren't as well protected as Secrets in both, the cluster and also the source of truth, i.e. Git repository or the like).
Alternatively use viper and let it handle precendence for us.
Describe the bug
When using OIDC then providing custom scopes via the
--custom-oidc-scopes
flag to the gitops-server binary doesn't result in the server actually requesting the scopes defined in the flag value.Environment
To Reproduce
oidc-auth
Secret with valid OIDC parametersgitops create dashboard wego --password=foo --export | yq e 'select(.kind == "HelmRelease") as $hr | select(.kind != "HelmRelease") as $o |$hr.spec.values.additionalArgs=["--custom-oidc-scopes=foo,bar"] | ($hr, $o)' | k apply -f-
k -n flux-system port-forward svc/wego-weave-gitops 9001
scope
URL query parameter doesn't have any of the values provided through the--custom-oidc-scopes
flagExpected behavior
The server should requests the scopes provided in the flag value.
Actual Behavior
The scopes provided in the flag value aren't used.
Additional Context (screenshots, logs, etc)
The reason for this happening is this line where the value is always overridden.