Hi Alexis, and anyone else reading this, Alexis Murzeau <amubtdx@gmail.com> writes: > I'm not sure how Qt webkit works, but I guess it behaves like a old > chrome browser. I don't know if it uses a different user agent, but > maybe Google doesn't recognize that it doesn't support newer web stuff. Exactly, that's what I'm wondering. In terms of cases, the possibilities I can think of are these cases (what you write above would be case #3): 1. Google refuses to talk to Qt webkit/QtWebEngine that identifies itself accurately. * Arguably the most correct thing to do here is for webkit and WebEngine to continue to accurate identify themselves, and only masquerade when absolutely necessary. Qt doesn't seem like the right place to maintain a huge list, so kaccounts-providers would override it with a sufficiently old enough Firefox version whose features it actually and functionally supports for the purposes of authenticating. Totally reasonable and with historical precedent. The ideal solution of course is a more open Web where Google stuff will continue to talk to non-Google, non-Apple, and non-Mozilla stuff. 2. Or Qt webkit self-identifies as a version of Firefox that is newer than what it can actually support. * In this case, there is a bug in Qt webkit that needs to be fixed. 3. Or Qt webkit masquerades as an old nonLTS version of Chrome, Chromium, or Firefox that Google has dropped support for. * As you note below, webkit appears dead upstream (replaced by QtWebEngine), and it would be wrong for it to masquerade as a browser whose features it can't actually support in the general case. Ie, probability of triggering bugs... I really hope this isn't where we find ourselves, but if this is where we are, then I guess we use kaccounts-providers to masquerade as a browser that webkit actually can't support...and we hope it doesn't break for a while. I believe that if we implement case #1 it will eventually become this case (#3). This workaround is definitely a "sweep the problem under the rug" type of hack. Yes, if it's the only solution then I think we'll have to implement it. > Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead. > I guess signon-ui should move to QtWebEngine instead but sadly upstream > seems rather dead :(, the previous signon-ui release was more than 5 > years ago. Yeah, signon-ui looks undermaintained/abandoned upstream... I'm adding the upstream maintainer to CC for notification about this nascent issue (Qt webkit removal), because it looks like signon-ui will break horribly at that time. As an aside, reading the copyright file makes it look like signon-ui may have originally been a Nokia project. > That's in fact why I've opened a report on this package, it seemed to be > the more feasible and realistic solution. Once again, thank you, much appreciated! And yes, I think that you have the right idea, and reported this bug in the right package. By the way, did you copy this solution from somewhere else (like Fedora's COPR or somewhere in Arch Linux), or is > It is a chance that google signon can still work :) > For sure! It's just a question of considering correctness as well as the long-term plan :) Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature