On 06.05.24 17:18, Thiago Macieira wrote: > On Monday 6 May 2024 00:02:58 GMT-7 Marc Mutz via Development wrote: >> Juha is currently improving the OAuth implementation in QtNetworkAuth. >> The protocol involves launching the system browser to get an access >> code, in turn used to get access tokens with which services can then be >> accessed. >> >> OAuth therefore requires a UI to run the browser in, but not necessarily >> a _G_UI (the system browser could be lynx). Even if a CLI tool like a >> mail fetcher, backup program, or VPN client will eventually launch >> Firefox or Chrome, I think it's too much to ask to link to QtGui just to >> do the equivalent of exec xdf-open <url>. > > That's true, but for such a restricted context that it's a negligible case. > > The chance that anyone who is using Qt has lynx or links as a web browser is > indistinguishable from zero. And the chance that the non-GUI browser they're > using is useful to perform an OAuth authentication is smaller than even that.
I agree about Lynx, but the main point was another. > Further, my experience with OAuth is that sometimes not even an external > browser suffices. Of the two cases I have a need for so far, one of them (Palo > Alto Networks' VPN product called "GlobalProtect") requires a full web engine > because the information that is required is stored in a cookie that is only > available in the response header. 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. > So, no, I don't think this should move. I don't think there's any situation > where *any* user is going to benefit from this in a non-GUI environment. A > class called QDesktopServices is really just about GUI desktops. Further, > QPlatformIntegration *IS* QPA. You can't move that class to QtCore. 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. > 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. Thanks, Marc -- Marc Mutz <marc.m...@qt.io> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
