azure-dev: [Issue] azd auth login does not use BROWSER env

Make sure you’ve installed the latest version using instructions in the wiki

Output from azd version Run azd version and copy and paste the output here: azd version 0.9.0-beta.3 (commit e564b122af7c1cb92bc54755f32930d661dddda2)

Describe the bug Despite having the BROWSER env var defined as “explorer.exe” - a not uncommon practice in WSL2 - I get an error when I try to run azd auth login:

ERROR: logging in: failed to authenticate: exec: "xdg-open,x-www-browser,www-browser": executable file not found in $PATH

I’d prefer not to install any of these as it pulls in a lot of dependencies I don’t need for WSL2, where I do most of my non-C# development.

To Reproduce

Provision a fresh distro in WSL2
Install azd
(Assuming bash): export BROWSER="explorer.exe"
azd auth login

Expected behavior My default browser should open.

Environment Information on your environment: * Language name and version: go version go1.20.1 linux/amd64 * IDE and version: none (WSL2)

About this issue

Original URL
State: closed
Created a year ago
Comments: 16 (14 by maintainers)

Most upvoted comments

FWIW - I opened https://github.com/AzureAD/microsoft-authentication-library-for-go/pull/422 in MSAL to give us the ability to configure what package is used to open the browser. With this change, we should be able to provide an implementation that honors BROWSER before falling back to xdg-open or the other tools that pkg/browser looks for.

ellismg on May 24, 2023

This auth flow works in other commands without wslu, though. While that works around the problem, not requiring additional dependencies that similar CLIs e.g., az don’t need would probably be ideal for user adoption and ease of use.

heaths on Jun 21, 2023

One thing to note is that we use a slightly different package in the implementation of azd monitor to open a web-browser, which IIRC is a fork of pkg/browser that the GitHub folks wrote, which also respects BROWSER before falling back to xdg-open.

It would be nice perhaps if the MSAL library allowed us to provide some function with a signature like OpenBrowser(url string) error so they didn’t have to have policy here, maybe we can open a PR.

@heaths, one thing to note, is that I think with --no-install-recommends the footprint of xdg-utils should be quite small, since I think it is just shell scripts. IIRC, xdg-open itself respects BROWSER when it is set.

You could also consider putting some simple xdg-open script on the path that just does $BROWSER $1 or something.

ellismg on May 23, 2023