az login on headless vm opens w3m due to a regression.

Describe the bug In a headless linux VM, doing az login opens www-browser and that in turn opens w3m, a text-only browser that does not support the device login flow.

To Reproduce ssh into headless VM without X forwarding. run az login.

Expected behavior Device code flow should get initiated, ie, i should see a URL and a code to enter there after opening it in a javascript-capable browser.

Environment summary I used the script install on linux to get the newest version.

Additional context This is a regression, which was introduced by this commit. Ie, it doesn’t check DISPLAY envvar anymore.

[temporaer]

@rayluo thank you for the summary, I think the most critical bit is missing though: az login on the headless VM (or docker container!) will open a text mode browser that completely hides the hint to use the --use-device-code flag (it’s running “full screen” in the terminal if you will). You have to first figure out how to exit that browser to see the hint.

I’m not sure what this transitional period is you mention, can you explain? To me, it seems the user experience will stay bad unless the can_launch_browser method is fixed.

Also note that contrary to your summary, the previous implementation of that function worked perfectly fine on WSL and opened a windows browser for login, not the device code flow.

[rayluo]

Describe the bug In a headless linux VM, doing az login opens www-browser and that in turn opens w3m, a text-only browser that does not support the device login flow.

To Reproduce ssh into headless VM without X forwarding. run az login.

Expected behavior Device code flow should get initiated, ie, i should see a URL and a code to enter there after opening it in a javascript-capable browser.

…

Additional context This is a regression, which was introduced by this commit. Ie, it doesn’t check DISPLAY envvar anymore.

Please allow me to take one step back to re-examine the situation here.

In this context, there are 2 methods for a user to sign-in:

1. Using a browser on the machine running your app (i.e. the az). This is the recommended approach, mainly because it is more user friendly, and more feature rich.
2. Usually, when/if there is no (capable?) browser on that machine, you can use a “device code flow” to complete the sign-in from a different machine.

The az login --use-device-code unambiguously uses method 2. The az login would generally attempt method 1, but historically it would automatically switch to method 2, when it believes method 1 would fail.

However, some traditionally “device-code only” scenarios are actually possible to still use method 1. For example, today the MSAL Python (which is the authentication library used by az 2.30+) is capable to facilitate a browser flow inside a local “text mode” docker container. Similarly, the scenario described by @temporaer , “ssh into headless VM without X forwarding”, could also perform a browser-based login, when/if the ssh session also opens a tunnel beforehand. (I believe az does not currently expose these features; nonetheless it can be an intriguing feature request.)

In summary, az login in v2.30+ does not aggressively fallback to device code flow. Instead, we hope the users would build a new habit of “if I want to use device code flow, I do az login --use-device-code. But if I do az login instead, I understand az will wait for either a browser flow’s potential success, or wait for me to manually cancel and switch to device code flow”. That being said, we understand that the user experience is not ideal, especially during this transitional period.