Origin: `oc whoami` should not return an error when logged out

[concaf]

When no user is logged in to the cluster, oc whoami should return system:anonymous, not an error.

Version

$ oc version
oc v3.7.1+ab0f056
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://192.168.42.245:8443
openshift v3.6.1+008f2d5
kubernetes v1.6.1+5115d708d7

Steps To Reproduce

1. Logout from the cluster
2. Run oc whoami

Current Result

$ oc whoami
Error from server (Forbidden): User "system:anonymous" cannot get users.user.openshift.io at the cluster scope

Expected Result

$ oc whoami
system:anonymous

[php-coder]

@enj @simo5

[jwforres]

@openshift/sig-security

[smarterclayton]

If we change this, anyone who has scripted this and expects that behavior would be broken. We could add a flag that ignores error on specific cases (although changing the API to allow anonymous access to users/~ would also break this).

[simo5]

Why do we care for not returning an error in this case @containscafeine ?

[concaf]

@simo5 for my use case, it's very useful when I'm shelling out to oc or when I'm scripting using oc to see if the user the user is logged in or not. oc whoami can return not zero exit codes in multiple cases like

• user not logged in
• server not reachable

If a user is not logged in, then I can simply parse the string system:anonymous.

Also, outside of my use case, well, the user is technically system:anonymous, which should be returned with a zero exit code.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[concaf]

hey @simo5, so what was decided on this?

[enj]

Based on Clayton's comment I will consider such a change backwards incompatible. Thus the existing behavior will not change.

[concaf]

I find this "closing the issue" behavior across the entire OpenShift ecosystem very weird. The OP is never communicated as to what exactly is wrong, the discussions are not really transparent and public, the communication is not clear and defaulting to closing the issue is actually very unwelcoming for a community to build.
I explained my use case, what is wrong with the use case? Is the suggested behavior suggested not correct? Why is it not correct? Encouraging incorrect user behavior/output due to implementation details and ignoring feedback is not the best way to lead a project IMO. Maybe just me! :man_shrugging:

[simo5]

@containscafeine the bug was closed because changing behavior is a backwards incompatible change and would break existing scripts. Although returning system:anonymous may be a reasonable choice, returning an error is also just fine because "anonymous" is not actually a user. Given there is no overwhelming advantage in changing behavior but there are downsides, we chose not to change behavior at this time.
Sorry if @enj sounded a bit dry, I am sure it was not intended.

[php-coder]

Could we introduce a command line parameter (for example, --no-fail-for-anonymous) that will activate a new behavior when it's specified?

[liggitt]

Could we introduce a command line parameter (for example, --no-fail-for-anonymous) that will activate a new behavior when it's specified?

It's not just command-line behavior. The CLI is just a wrapper around the /apis/users.openshift.io/~ API. When anonymous, that returns:

GET https://<server>:8443/apis/user.openshift.io/v1/users/~ 403 Forbidden in 5 milliseconds
I0529 11:07:11.081454   14113 helpers.go:207] server response object: [{
  "metadata": {},
  "status": "Failure",
  "message": "users.user.openshift.io \"~\" is forbidden: User \"system:anonymous\" cannot get users.user.openshift.io at the cluster scope: User \"system:anonymous\" cannot get users.user.openshift.io at the cluster scope",
  "reason": "Forbidden",
  "details": {
    "name": "~",
    "group": "user.openshift.io",
    "kind": "users"
  },
  "code": 403
}]

[php-coder]

@liggitt ... and I don't see why CLI can't have more logic to handle such a specific case. The simple check like if strings.Contains(response.message, "User \"system:anonymous\" cannot get") would be sufficient IMHO.

[liggitt]

The simple check like if strings.Contains(response.message, "User \"system:anonymous\" cannot get") would be sufficient IMHO.

That is precisely the sort of logic we want to avoid baking into our CLI. Strings of error messages are not an API, and that treats it like one.

[php-coder]

That is precisely the sort of logic we want to avoid baking into our CLI.

:-)

@containscafeine Sorry, you see, it mostly impossible to change something now :-/

[concaf]

Thanks for this conversation, I understand this now.
Sorry for being a bit rough in the previous comments :)