Skip to content

Speed up SAML Auth: Open the SAML URL and close the tab automatically#1332

Open
sk-tractive wants to merge 1 commit into
adrienverge:masterfrom
sk-tractive:saml-speedup
Open

Speed up SAML Auth: Open the SAML URL and close the tab automatically#1332
sk-tractive wants to merge 1 commit into
adrienverge:masterfrom
sk-tractive:saml-speedup

Conversation

@sk-tractive
Copy link
Copy Markdown

Problem

When using SAML login (--saml-login), the user has to do two manual steps:

  1. Click the URL in the output of openfortivpn so it opens in the browser.
  2. Close the tab after successfull authentication (only auto-closes after 5 seconds)

I wanted SAML login without those two manual steps

Solution

I added two options:

  • --saml-auto-open automatically opens the URL in the user's default browser. Also detects if run with sudo and opens the browser for the original user. Uses xdg-open on Linux and open on macOS.
  • --saml-instant-close instantly closes the browser tab after successfull SAML login with window.close();, doesn't wait 5 seconds.

Example usage:

sudo openfortivpn vpn.example.com --saml-login --saml-auto-open --saml-instant-close

It's quite convenient and could also be the default, at least --saml-auto-open, but for now it's just two extra command line arguments.

for a faster SAML auth experience
@DirkDuesentrieb
Copy link
Copy Markdown

If your commit starts the default browser in my userspace (not privileged) it has my sympathy.
I don't like the current intricate copy and paste method.

@sk-tractive
Copy link
Copy Markdown
Author

If your commit starts the default browser in my userspace (not privileged) it has my sympathy.

@DirkDuesentrieb Absolutely, it opens the default browser for the current user (Linux: xdg-open, Mac: open), works even when it was called with sudo.

On Linux this line does it:

sprintf(cmd, "sudo -u %s xdg-open '%s' 2>/dev/null", sudo_user, url);

macOS:

sprintf(cmd, "sudo -u %s open '%s'", sudo_user, url);

@fabianonunes
Copy link
Copy Markdown
Contributor

fabianonunes commented Apr 15, 2026

This is a great idea, but it's not working properly for me. I use Firefox, and if it is already open, the command sudo -u username xdg-open https://... shows a popup saying "Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile."

Another problem happens when the browser is not already open. Since Firefox is launched in the same process group as openfortivpn, when I close openfortivpn, Firefox is closed too. And not gracefully, because in one of my tests, Firefox warned me on the next launch that something might be corrupted (I don't remember the exact phrase).

I think both problems can be fixed by forking and running xdg-open in a new process group.

I also found that some environment variables need to be set for the browser work correctly. Without XDG_RUNTIME_DIR, audio fails (it seems PipeWire can't work) and without WAYLAND_DISPLAY Firefox starts in X11 mode instead of Wayland, which causes video glitches.

DBUS_SESSION_BUS_ADDRESS also needs to be set, because it allows xdg-open to reach the already running Firefox instance, solving the "already running" popup mentioned above.

Instead of passing individual env variables, we could recommend passing -E (--preserve-env) to sudo, which would make Firefox inherit all these user variables. But I think, at least on Ubuntu's new Rust based implementation, sudo doesn't support environment preservation, so we can't rely on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants