Adding UpcomingSprint, actively working on this.

this got away from me with other bugs taking priority, adding upcoming sprint

This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Additionally, you can add LifecycleFrozen into Keywords if you think this bug should never be marked as stale. Please consult with bug assignee before you do that.

The issue can be reproduce with cluster 4.7:
[root@dhcp-140-138 ~]# oc login https://api.yinzhou0104.qe.devcluster.openshift.com:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou0104.qe.devcluster.openshift.com/oauth/token/request
[root@dhcp-140-138 ~]# oc version 
Client Version: 4.7.0-202012220147.p0-8fbc95f

I finally have looked into this bug and it appears all is working as intended. Please re-open if I'm missing something. Please see this change, https://github.com/openshift/oc/pull/553.

* If a user provides `oc login -u anything`, user will get the basic auth prompt. 
* If there is only password IDP available, and no username was provided, show the tokenURL message instead of a basic auth prompt.

Also, I am not able to reproduce the issue from the comment above, with logging into api.ci.openshift.org and an oc 4.7 client.
I see the prompt to get the token like so, 

$ oc login https://api.ci.openshift.org 
Login failed (401 Unauthorized)
Verify you have provided correct credentials.
You must obtain an API token by visiting https://api.ci.openshift.org/oauth/token/request

and then this works as expected after obtaining the login cmd:
$ oc login --token=REDACTED --server=https://api.ci.openshift.org

This doesn't work `as expected` if the user's expectations are that the same process that worked for them in 4.1 -> 4.6 will work in 4.7.

Previously a user could do `oc login --server=<url>` initially and enter credentials. Once the initial login expired they could simply `oc login` and be prompted for credentials.

At best this is now broken, with an indirect and inconvenient workaround. Compare:

1) Load the web UI
2) Enter credentials to log in
3) Click your name in the upper right
4) Click "Copy Login Command"
5) Enter credentials to log in *again*
6) Click "display token"
7) Highlight the command
8) Copy the command to the clipboard
9) Return to the console
10) Paste the login token

With:

1) Type "oc login"
2) Enter credentials to log in

Users should also be uncomfortable with doing this process on a shared screen, as participants may be able to take a screen capture and reuse the token.

I'm reopening this.
~~~
[root@openshift-jumpserver-0 ~]# oc login
You must obtain an API token by visiting https://oauth-openshift.apps.ipi-cluster.example.com/oauth/token/request
[root@openshift-jumpserver-0 ~]# oc version
Client Version: 4.7.5
Server Version: 4.7.5
Kubernetes Version: v1.20.0+bafe72f
~~~

Just to reiterate, the workaround is to provide a username on the CLI with --username:
~~~
[root@openshift-jumpserver-0 ~]# oc login --username=myself
Authentication required for https://api.ipi-cluster.example.com:6443 (openshift)
Username: myself
Password: 
~~~

I agree though with the assessment from the previous comment. At best, it is not nice to change a user facing component, at worst, it is really frustrating. And our users should not have to google or guess to figure this out.

If we really must change the `oc` CLI behavior (and likely there is a good reason for this change) and if we cannot default back to the old, well-known behavior, we should at least provide a Note/Warning to users for the next few versions such as:
~~~
[root@openshift-jumpserver-0 ~]# oc login
You must obtain an API token by visiting https://oauth-openshift.apps.ipi-cluster.example.com/oauth/token/request
INFO: The behavior of `oc login` changed.
INFO: If you wish to login via username and password prompt, provide the --username <username> parameter
~~~

Thanks,

Andreas

Also see
https://github.com/code-ready/crc/issues/2032

We have the same behaviour now on 4.6.20 which is not nice since our colleagues are asking why this happened, there should be at least something easily visible in the changelogs or so. 

Is this behaviour intended, and if yes, how can we override this? This is an additional step for everybody (I guess it can be done via a snippet or so?)

The docs here (please note, 4.6): https://docs.openshift.com/container-platform/4.6/cli_reference/openshift_cli/getting-started-cli.html say that one needs to use "oc login" without the "-u" option, the 4.7 docs are upgraded. 

If this was intended it is a rather breaking change from a user perspective which came in with a minor upgrade.

The docs have been updated for 4.7. I don't see this change in 4.6, however.
4.7:  https://github.com/openshift/oc/blob/release-4.7/pkg/helpers/tokencmd/basicauth.go#L17-#L28

I've opened this to guide users to provide username for password prompt when the BasicAuthNoUsername error is thrown. 
https://github.com/openshift/oc/pull/834

As far as I can tell this doesn’t restore the original functionality, or explain why it’s necessary to break existing behavior.

Also related https://bugzilla.redhat.com/show_bug.cgi?id=1939403

The default prompt is : 

[root@localhost ~]# oc login https://api.yinzhou.qe.gcp.devcluster.openshift.com:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou.qe.gcp.devcluster.openshift.com/oauth/token/request

Only with `-v 2` could see the guide infomation :

[root@localhost ~]# oc login https://api.yinzhou.qe.gcp.devcluster.openshift.com:6443 -v 2
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

I0611 09:25:01.288043 1901866 request_token.go:240] did not receive username. Pass 'oc login --username <username>' for the password prompt
You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou.qe.gcp.devcluster.openshift.com/oauth/token/request


Could we prompt the guide infomation default ?

There's still no explanation as to why the existing behavior needs to change.

What is the aim of forcing people to give the username as a parameter instead of interactively prompting for it?

Whatever this is meant to convey to the user (or to the cluster admin?), it isn't doing the job.

Is there a reason why it's preferred to force users to specify the flag instead of entering it at a prompt?

(In reply to Chet Hosey from comment #16)
> Is there a reason why it's preferred to force users to specify the flag
> instead of entering it at a prompt?

See https://bugzilla.redhat.com/show_bug.cgi?id=1939403 for details behind that decision


(In reply to zhou ying from comment #15)
> Could we prompt the guide infomation default ?

I'll see what's possible.

(In reply to Maciej Szulik from comment #17)
> (In reply to Chet Hosey from comment #16)
> > Is there a reason why it's preferred to force users to specify the flag
> > instead of entering it at a prompt?
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=1939403 for details behind
> that decision

The only justification I saw is that it’s meant to encourage administrators to disable the default user account.

It’s not clear how breaking the login process for existing users is the best way to convey that message.

And, having disabled the kubeadmin user immediately after installation long ago, the prompt isn’t restored.

Can you help me to understand how making users specify their ID as an argument instead of prompting interactively for it achieves the stated goal of getting admins to disable the default account? Might there instead be a warning on the administration console, encouraging the administrator to disable the account at their earliest opportunity?

Or if the goal is to get people to avoid using the interactive login, might a warning before the interactive prompt suffice?

Ideally there would be an explanation as to why entering my Active Directory credentials in the browser is more secure than providing them via the CLI.

If that’s really the case, might that be treated as a bug in itself rather than using inconvenience to discourage CLI login?

And if it’s not the case, I’m afraid I just don’t understand the goal of this change.

We're hoping to to change the flow in one of next releases such that this entire flow will be significantly simpler, apologies for the inconvenience in the mean time.

Since https://bugzilla.redhat.com/show_bug.cgi?id=1893999#c15 has confirmed the PR for this issue , will move to verified .

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438

(In reply to Maciej Szulik from comment #21)
> We're hoping to to change the flow in one of next releases such that this
> entire flow will be significantly simpler, apologies for the inconvenience
> in the mean time.

How could it be simpler than the original functionality?

Why not just warn when the user enters "kubeadmin" as a username?

What is the actual benefit of making this process harder for users? And might there be a better way of getting the same results that doesn't make the process harder for everyone?

Are there plans to backport this to 4.7.x?

(In reply to brian from comment #26)
> Are there plans to backport this to 4.7.x?

Nope, since this will required server-side changes implemented before we do that on the oc side.