Unable to Install on MacOS

[whois-sin]

OS: MacOS Monterey

I'm trying to install an application that uses GTK, which requires python3 bindings and I'm not able to find a way to install WebKit2. Since I'm using homebrew as a package manager so installing via macports may not be a viable solution. Additionally, I've seen that it hasn't worked for other's using macports as well.

I installed gtk+3 and pygobject which fulfill most of the other dependency requirements, allow me to pip install the script, but I get the following error message when trying to execute it:

raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Webkit2 not available

Are there any other ways to install WebKit2 on MacOS?

[dlenski]

Standard disclaimer about macOS support in my projects

If anyone else who does use or understand macOS has any useful input here, go for it.

[lkrms]

After spending far too many hours trying fruitlessly to get WebKit2GTK to build on macOS, I went in a different direction to get this running as smoothly on macOS as it does on Linux.

It's not quite PR-ready yet, and @dlenski may not be interested in a PR that complicates gp-saml-gui's dependencies anyway, but after identifying pywebview as the most likely to work, I've created a fork that uses it

1. as a fallback if WebKit2 fails to import (whether it's missing or the wrong version is installed), and
2. if --pywebview is given on the command line (this is only for testing purposes; there's no reason to prefer pywebview if WebKit2 is working).

As far as logging and debugging goes, pywebview is less capable than WebKit2, largely because it doesn't surface many events during the lifecycle of a request or allow inspection of request or response headers. The lack of HTTP headers almost brought my efforts to an early conclusion, but then I discovered that GlobalProtect (or the version I'm connecting to, anyway) delivers the same values in the body of its responses--where pywebview can see it 🎉--the script is already collecting from its headers. They're enclosed between HTML comment tags like so:

<!-- <saml-auth-status>{{STATUS}}</saml-auth-status><prelogin-cookie>{{COOKIE}}</prelogin-cookie><saml-username>{{USERNAME}}</saml-username><saml-slo>{{SLO}}</saml-slo> -->

So, setting aside verbose logging of requests, I've been able to replicate the critical features of SAMLLoginView in a pywebview-bound alternative class, SAMLLoginViewWebview, but it could use more testing (on Macs and also on Linux/Windows, to ensure there aren't any regressions), not to mention whatever improvements @dlenski needs.

Here's the link again; test away: https://github.com/lkrms/gp-saml-gui/tree/lkrms/pywebview

Hopefully this works on macs other than mine 😃

[dlenski]

First of all, nice work @lkrms!

It's not quite PR-ready yet, and @dlenski may not be interested in a PR that complicates gp-saml-gui's dependencies anyway, but after identifying pywebview as the most likely to work, I've created a fork that uses it

Huh, very interesting. https://github.com/dlenski/gp-saml-gui/compare/master...lkrms:gp-saml-gui:lkrms/pywebview

As far as logging and debugging goes, pywebview is less capable than WebKit2, largely because it doesn't surface many events during the lifecycle of a request or allow inspection of request or response headers.

Oof, that seems pretty important. If PyWebView had all of the necessary features, and were easier to support cross-platform, I might be tempted to say "let's just switch to that."

The lack of HTTP headers almost brought my efforts to an early conclusion, but then I discovered that GlobalProtect (or the version I'm connecting to, anyway) delivers the same values in the body of its responses--where pywebview can see it tada--the script is already collecting from its headers. They're enclosed between HTML comment tags like so:

<!-- <saml-auth-status>{{STATUS}}</saml-auth-status><prelogin-cookie>{{COOKIE}}</prelogin-cookie><saml-username>{{USERNAME}}</saml-username><saml-slo>{{SLO}}</saml-slo> -->

Yeah… most GP+SAML VPNs do send this, but unfortunately not all. :frowning_face:

Any idea why pywebview doesn't have any mechanism to inspect headers?

[lkrms]

Oof, that seems pretty important. If PyWebView had all of the necessary features, and were easier to support cross-platform, I might be tempted to say "let's just switch to that."

Indeed. I'd prefer not to introduce a separate fallback class--the code is inelegant and in its current form, several features inexplicably stop working if WebKitGTK is unavailable at runtime--but there were going to be too many losses if I switched.

Yeah… most GP+SAML VPNs do send this, but unfortunately not all. frowning_face

I mean, of course they don't all send it. Why would they? bangs head on wall

Any idea why pywebview doesn't have any mechanism to inspect headers?

I'm not sure if it's because of upstream shortcomings in pywebview's native dependencies, or if there just hasn't been a need. I'll look into it... and/or continue the hunt for a more appropriate alternative 😬

If pywebview could inspect headers and control TLS settings, it would be workable. If it also raised events per-resource (at the moment it only raises "onload" per-page), there would be zero loss of functionality.

[lkrms]

Update:

• wxPython has a solid-looking webview implementation, but it doesn't surface HTTP headers directly, so something clever would need to be done with GetNativeBackend() for ... all the platforms. Plus it's a non-trivial dependency to have. No dice.

• Other Python options I've found have either been abandoned, are coupled to one backend (e.g. WebKitGTK or Qt), or are kitchen-sink electron alternatives, and none of them appear to surface HTTP messages. 🤯

• Python bindings for the popular webview library don't appear to be maintained and as best I can tell, HTTP message inspection isn't supported anyway.

So working with pywebview seems to be the best option. I've already checked out the work involved in adding response inspection to its Cocoa and WebView2 backends, and it doesn't seem to be too difficult, plus it would be a good to contribute to such a helpful library regardless.

[mojibake-umd]

Don't know if it is of any help, on On Ubuntu 20.04 I believe it defaults to using LuaKit, at least that is what I have traced it to when I was tracking down an issue before.

[mwolfe]

@lkrms Thank you! I downloaded your modded version and it worked like a charm on my mac - and at least for my place's GP VPN/Okta. For some reason I couldn't get pip to install it properly so I just ran the .py

./gp_saml_gui.py -S --allow-insecure-crypto --pywebview --clientos=Mac vpn.example.com -- --csd-wrapper=/opt/local/libexec/openconnect/hipreport.sh --no-dtls

[bobspryn]

@lkrms Mind adding installation instructions for the Mac on your fork?

[lkrms]

So I haven't had the time or headspace to surface headers via pywebview 😞 and although it's had a few updates in the meantime, this isn't a feature that has materialised.

To simplify things until a more elegant solution arises, I've rebased my fork and added an update that restores cookie storage on pywebview 4+. And hopefully the Homebrew formula works for others (let me know if not):

brew install lkrms/misc/gp-saml-gui

[tofra]

So I haven't had the time or headspace to surface headers via pywebview 😞 and although it's had a few updates in the meantime, this isn't a feature that has materialised.

To simplify things until a more elegant solution arises, I've rebased my fork and added an update that restores cookie storage on pywebview 4+. And hopefully the Homebrew formula works for others (let me know if not):

brew install lkrms/misc/gp-saml-gui

Install works, but I'm missing WebKit2 probably. Any idea how to get that in mac? ValueError: Namespace WebKit2 not available

[lkrms]

Hmmm, the lack of WebKit2 support on macOS is the issue that's supposed to be addressed by the fork, so you shouldn't be seeing that error. Would you mind sending the full error message, please? A stack trace would be great.

(And to avoid spamming everybody, I'm happy for you to open an issue here for the minutiae.)

[tofra]

Hmmm, the lack of WebKit2 support on macOS is the issue that's supposed to be addressed by the fork, so you shouldn't be seeing that error. Would you mind sending the full error message, please? A stack trace would be great.

(And to avoid spamming everybody, I'm happy for you to open an issue here for the minutiae.)

After really cleaning up all old stuff, and reinstalling it worked. I guess there was some leftover from dlenski/gp-saml-gui left.