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)
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 thatpkg/browser
looks for.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.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 ofxdg-utils
should be quite small, since I think it is just shell scripts. IIRC,xdg-open
itself respectsBROWSER
when it is set.You could also consider putting some simple
xdg-open
script on the path that just does$BROWSER $1
or something.