Dear Maintainer,

When trying to login to a google account to use google drive with kio-gdrive,
the authentication hang.

The reproduction steps are:
- Open systemsettings
- Go to online accounts
- Add a new account and choose "Google"
- A webpage dialog is opened with the google login page
- Enter the username then click on "Next" on the google login page
- The webpage hangs there and never goes to the next page


To fix this, I've put this line in /etc/signon-ui/webkit-
options.d/accounts.google.com.conf:
UserAgent = Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
Firefox/77.0

The webpage issue is maybe caused by the use of Qt webkit, using an older
UserAgent probably causes Google to offer an older login page that works with
Qt webkit.

As the UserAgent is required to make the login work, can it be added to the
package ?

*** End of the template - remove these template lines ***

Hi,

Thank you for reporting this bug.

Alexis Murzeau <amubtdx@gmail.com> writes:

I've tested this proposal, and it fixes Google signon for me.  This will
transitively fix things like kio-gdrive that are broken in bookworm; For
users of Google things, Bookworm's KDE is a poor user experience, or
"bad story", compared to GNOME.

That sounds plausible to me.  If that's the case then it seems like it
may be better to patch Qt webkit.  I wonder if this is a case where
whatever UserAgent Qt webkit validated is the one the package declares
(where it shouldn't be overridden for the general case), or if everybody
involved just forgot to update it?

Agreed, either Qt webkit should be fixed, or else kaccount-providers
should begin overriding UserAgent.  It's nice to see a Google issue that
we can fix on our side!

Best,
Nicholas

Hi,

Thanks for your reply!


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.

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.

That's in fact why I've opened a report on this package, it seemed to be
the more feasible and realistic solution.
It is a chance that google signon can still work :)

Hi Alexis, and anyone else reading this,

Alexis Murzeau <amubtdx@gmail.com> writes:

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.

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.

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

For sure!  It's just a question of considering correctness as well as
the long-term plan :)

Regards,
Nicholas

I've got this solution from someone on internet, but I can't find it
again (something like reddit or a forum IIRC).

I will be able to check my browse history only this week-end as I'm not
on the same PC currently.

Hi,

I received a report from sney (in #debian-qt-kde on OFTC) that a
workaround is no longer necessary in either kaccounts-providers or
signon-ui.

Thus it sounds like this was a case #1 problem
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#24)

    1. Google refuses to talk to Qt webkit/QtWebEngine that identifies
    itself accurately.

and it appears that they've reverted the action that broke everyone's
access to their Google accounts.  This is the most correct solution and
the best possible outcome.

Alexis and Peter, would you please confirm that the workaround is no
longer necessary?  And please leave the bug open even if Google accounts
are working again, because the frequency of this breakage has been
mounting.

To everyone reading this: If user spoofing doesn't solve the next
incidence of breakage then that would indicate a separate issue, and
please file a separate bug in this case!

Cheers,
Nicholas

Hi,
I confirm that Google authentication and gdrive now work without using
hacks.

Best regards
Peter

I can login into my google account.

I found where I got this workaround, this is what has done dabiswas112
in a fedora COPR in hazel-bunny/ports:
https://github.com/hazel-bunny/rpm-packaging/blob/master/lib/signon/signon-ui/fake-user-agent.patch

This COPR was suggested here:
https://bugzilla.redhat.com/show_bug.cgi?id=2230099.