On Monday 6 May 2024 23:08:07 GMT-7 Marc Mutz via Development wrote: > Such applications wouldn't use QNetworkAuth, though, because returning > access codes by cookie isn't one of the standardized mechanisms, and > therefore not implemented in QNetworkAuth. I can see this bahviour every > week when Thunderbird or the Linux "native" Teams client have kicked me > out and ask for the password again. Both don't spin the system browser, > and so I need to copy my password from Firefox to their own shitty > dialogs manually each time. Very annoying, but that's precisely _not_ > what the spec asks for, either.
BTW, the other need I have is Microsoft's email service. And for that, I highly recommend https://github.com/simonrob/email-oauth2-proxy. I've attached my GUIless .service file. Whenever I need to re-authenticate, I look up the journal logs and click the link that shows up there. I agree this is not the best UX for most people. It works for me and I may guess some of you here. > I'm currently fighting an older version of openfortifyvpn (CLI on Linux) > which cannot, yet, spin up the browser. Newer versions are reported to > be able to, so there you have your use case. Plus mail fetchers, backup > clients, basically everything that needs to authenticate with a web > service of any kind needs OAuth support these days, and we can't ask all > of them to embed QtWebEngine. Speaking with my security hat on, even the > QtGui dependency would be a complete no-no for such applications: One > should never, ever, link to libraries one doesn't need, as that does > nothing but increase the amount of potentially exploitable code in the > process' address space. That's a fair argument. I don't think those are going to be GUI-less Qt applications, though. That number I still believe to be zero. They may be GUI Qt applications, such as system tray services. A good example would be the VPN: you need a way to turn it on and off (on Linux ,that's already implemented and is called NetworkManager). I'd like to see some GUI-less Qt applications perform those services, but then they are highly limited on how to start the browser in the first place. Anything beyond "print URL to stdout" may not be acceptable at all, as they may be running *in* a GUI-less environment, such as my emailproxy case. > > I suggest having a background hook that QPA registers with QtCore so that > > QtNetwork can use to launch the browser if QPA has been loaded, but shall > > fail if not. > > That doesn't solve the openfortifypn use-case, though. We can debate > whether it's a valid one, but I think I just did. It doesn't change the technical roadblock: you *cannot* *move* QDesktopServices. The best you can do for API is add a new one. So I'd like an argument why it needs to be separate from QDesktopServices when we already have that and cannot remove it until Qt 7. And I'd like an argument why the API should be in QtCore, as opposed to QtNetwork (it's a browser after all). -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering
# -*- conf -*-
[Unit]
Description=Service for the Microsoft365 OAuth2 proxying
ConditionPathExists=/etc/emailproxy/emailproxy.config
[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectProc=noaccess
ProtectSystem=strict
RestrictAddressFamilies=AF_UNIX AF_INET
UMask=077
ConfigurationDirectory=emailproxy
CacheDirectory=emailproxy
CacheDirectoryMode=0700
ExecStart=python3 /usr/local/bin/emailproxy.py --no-gui --local-server-auth --config-file ${CONFIGURATION_DIRECTORY}/emailproxy.config --cache-store ${CACHE_DIRECTORY}/auth-cache
Group=emailproxy
User=emailproxy
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
