You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This makes it hard for the user to debug the settings in their OIDC provider if they have configured the client wrong.
What did you expect to happen?
The text of the error could be shown.
What is the simplest way to reproduce this behavior?
Do something that will cause an error at the token endpoint. For example, configure the client to require client auth using a client secret. This should cause the token endpoint to return an error, because the Pinniped CLI will not send a client secret. That should reproduce the error being hidden from the CLI user.
In what environment did you see this bug?
Pinniped server version:
Pinniped client version:
Pinniped container image (if using a public container image):
Pinniped configuration (what IDP(s) are you using? what downstream credential minting mechanisms are you using?):
Kubernetes version (use kubectl version):
Kubernetes installer & version (e.g., kubeadm version):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Others:
What else is there to know about this bug?
The text was updated successfully, but these errors were encountered:
What happened?
See https://kubernetes.slack.com/archives/C01BW364RJA/p1687991154864069?thread_ts=1687985547.285319&cid=C01BW364RJA. This community user was trying to configure the CLI to use an OIDC identity provider without using the Pinniped Supervisor. They were using Azure AD as the OIDC identity provider, although this problem is not specific to Azure AD.
When there is an error returned by the OIDC provider's token endpoint, the CLI does not show the details of the error to the user on this line: https://github.com/vmware-tanzu/pinniped/blob/v0.24.0/pkg/oidcclient/login.go#L941
This makes it hard for the user to debug the settings in their OIDC provider if they have configured the client wrong.
What did you expect to happen?
The text of the error could be shown.
What is the simplest way to reproduce this behavior?
Do something that will cause an error at the token endpoint. For example, configure the client to require client auth using a client secret. This should cause the token endpoint to return an error, because the Pinniped CLI will not send a client secret. That should reproduce the error being hidden from the CLI user.
In what environment did you see this bug?
kubectl version
):kubeadm version
):cat /etc/os-release
):uname -a
):What else is there to know about this bug?
The text was updated successfully, but these errors were encountered: