Skip to content

Check for xdg-open availability on Linux for browser auth #2254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
kyle-rader-msft wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Check for xdg-open availability on Linux for browser auth #2254

kyle-rader-msft wants to merge 3 commits into from
+27 −37

Conversation

@kyle-rader-msft
Copy link

@kyle-rader-msft kyle-rader-msft commented Jan 29, 2026 •
edited
Loading

Summary

Check for browser launcher availability (xdg-open, gnome-open, etc.) in addition to checking for desktop session presence to gate web auth flow.

Problem

GCM currently only checks for DISPLAY or WAYLAND_DISPLAY environment variables to determine if browser-based authentication is available on Linux. However, MSAL checks for xdg-open availability in addition to display environment variables. This creates a mismatch where GCM reports "browser not available" even though MSAL can successfully launch a browser using xdg-open.

Real-World BLocker: WaveSpace VMs

This fix isimportant for WaveSpace VMs and similar environments where:

  • Users connect via SSH without X11 forwarding (no DISPLAY environment variable)
  • xdg-open is available and can launch the host system's browser (this is setup by VSCode remote tunnels)
  • Browser-based authentication needs to work for conditional access policies, satisifed by the host's browser (Microsoft Edge in this case).

Solution

Modified LinuxSessionManager.GetWebBrowserAvailable() to return true if:

  • An interactive desktop session is detected (existing behavior via DISPLAY/WAYLAND_DISPLAY), OR
  • A shell execute handler like xdg-open is available (new behavior)

This matches MSAL's browser detection logic and ensures GCM, AzureAuth and MSAL behave consistently.

Behavior Changes

Scenario Before After
Linux with DISPLAY set ✅ Browser available ✅ Browser available
Linux with WAYLAND_DISPLAY set ✅ Browser available ✅ Browser available
Linux with xdg-open but no DISPLAY ❌ Browser NOT available ✅ Browser available (FIXED)
Linux without display vars or browser launchers ❌ Browser NOT available ❌ Browser NOT available

Testing

  • ✅ Solution builds successfully with no warnings
  • Manual testing recommended on Linux system without DISPLAY but with xdg-open available
  • Verify OAuth authentication works in SSH sessions with xdg-open present

🤖 Generated with Claude Code
@claude
Check for xdg-open availability on Linux for browser auth
69a1f88 
Enhanced LinuxSessionManager.GetWebBrowserAvailable() to check for
browser launcher availability (xdg-open, gnome-open, etc.) in addition
to checking for desktop session. This matches MSAL's behavior and fixes
the scenario where GCM reports "browser not available" even though MSAL
can successfully launch a browser using xdg-open (e.g., in SSH sessions
without X11 forwarding but with xdg-open available).

The IsDesktopSession property remains unchanged and focused on detecting
X11/Wayland desktop environments. Only the IsWebBrowserAvailable check
has been enhanced.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@kyle-rader-msft kyle-rader-msft requested a review from a team as a code owner January 29, 2026 08:06
mjcheetham
mjcheetham requested changes Jan 29, 2026
View reviewed changes
Kyle Rader added 2 commits January 29, 2026 10:46
Refactor: invert handler check for clearer logic
cc81292 
Move shell execute handler check to top with early return if handler
exists (with WSL session 0 exception). This makes the logic flow more
clearly and avoids redundant checks between WSL and non-WSL paths.

Logic now:
- If handler exists (xdg-open, wslview, etc.): return true (early exit)
  * Exception: WSL session 0 returns false
- If no handler and WSL: return false
- If no handler and non-WSL: fall back to IsDesktopSession check
Simplify logic with explicit boolean vars and single return
0b7e96a 
Refactored GetWebBrowserAvailable() to be much more readable:
- Define all boolean properties upfront (hasHandler, isWsl, etc.)
- Single return statement expressing the complete logic clearly
- No nested conditionals or multiple return paths

Logic: (hasHandler && !isWslSession0) || (isDesktopSession && !isWsl && !hasHandler)
@becm
Copy link
Contributor

becm commented Jan 29, 2026 •
edited
Loading

@mjcheetham return of GetWebBrowserAvailable() may not block on missing Linux utilities.
Current WSL detection redirects requests to the host system just fine without them.
Or maybe not yet, BrowserUtils.OpenDefaultBrowser() seems to not handle WSL in a special way…

The presence of wslview is an esoteric corner case and likely breaks similar to our existing logic
(e.g.: WSL interop is disabled → #1813).

The problem here is HOW to detect if any open tool is properly set up to redirect to a UI-capable system?
@becm
Copy link
Contributor

becm commented Jan 29, 2026

Next debatable design; none of the listed open tools in BrowserUtils.cs guarantee there IS a usable browser installed (same issue in the linked MSAL proxy lookup).

So in a proper desktop session, valid programs would rather be
["x-www-browser", "www-browser", <other known UI HTTPS applications>].

If possible, detection of WSL-interop or other redirect condition is independent from availability of local browsers.
@kyle-rader-msft
Copy link
Author

kyle-rader-msft commented Jan 30, 2026 •
edited
Loading

The primary issue we are hitting is that out the box - GCM does not work anymore on remote WaveSpace VMs for Msft devs using Linux VMs through VSCode remote tunnel. GCM falls back to device code, and the device code flow no longer passes conditional access and we are totally blocked.

The VSCode remote tunnel sets up a $BROWSER and xdg-open. The $BROWSER script triggers launching through the host and your host web browser on the Intuned machine passes CA and can log in just fine.

AzureAuth does this, and so does the Azure CLI.
@becm
Copy link
Contributor

becm commented Jan 30, 2026 •
edited
Loading

@kyle-rader-msft based on your description, the presence of a BROWSER environment variable would be the highest ranked indicator for using exactly this (non-standard) tool.
Even most UI sessions no longer set this variable (or override).

Based on that assumption my personal preference would be to just add code path for using this variable at the beginning of GetWebBrowserAvailable() and OpenDefaultBrowser().
It's a much stronger indicator the user wants to use a specific HTTP handler, than any of the other magic we can do to deduce a working setup.

But @mjcheetham (or other maintainers) will have to decide if this may be a more robust approach.
Or if there are some bad drawbacks.
@becm
Copy link
Contributor

becm commented Jan 30, 2026

The code for xdg-open has nice examples for:

  • multi value split of $BROWSER using : as delimiter
  • non-standard invocation using %s to support non-standard calls apart from <executable> <URL>

There is also a good default selection of actual web browsers for UI and command line.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants

@kyle-rader-msft @becm @mjcheetham