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. 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. 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 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
