Bug 480779

Sorry, versions:

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  KDE Neon Unstable
(available in About System)
KDE Plasma Version: 6.0.80
KDE Frameworks Version: 5.249.0
Qt Version: 6.6.1

Indeed, it looks like we're going to need to make some changes here.

Works fine for me on Fedora Rawhide. Likely has to do with signon-ui/QtWebengine, but there's no obvious difference between Fedora and Neon as far as I can tell

*** Bug 482808 has been marked as a duplicate of this bug. ***

I can reproduce this bug on my machine. 

Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.8-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5625U with Radeon Graphics
Memory: 14.5 GiB of RAM
Graphics Processor: AMD Radeon Graphics

Hi all, I can confirm this bug either in a HP Zbook running Plasma 6.00 and also in a virtual machine running VMWare also running Plasma 6.00.
My google account is 2FA activated.
If you need more details, just let me know.

I have he same issue on KDE Neon based on Ubuntu 22.04 with KDE 6 upgraded from KDE 5.

Additionally, existing Google accounts do not show any files any more (the loading never stops).

Running systemsettings from the command line and trying to add a new google account I get:

"google"
Looking for plugin ""
Starting auth session with "oauth2"
Info:
        Id: 105
        caption: "google"
        owner: ""
        userName: ""
qt.dbus.integration: Could not disconnect "com.google.code.AccountsSSO.SingleSignOn.Identity" to "destroyed(QObject*)" : Pointers are not supported: QObject*


This occurs in a Gentoo system with plasma-6.0.3 with qt-6.7.0

*** Bug 484741 has been marked as a duplicate of this bug. ***

*** Bug 489645 has been marked as a duplicate of this bug. ***

*** Bug 489435 has been marked as a duplicate of this bug. ***

I'm 99% sure that "qt.dbus.integration" error from post #8 is not related to the issue at hands, and in fact is just a side effect of automatic runtime method registration which was not supposed to register the pre-descruction signal.

I just tripped on this, and here's a workaround that worked for me, combined from an earlier workaround posted in #485286 and my own experimentation:

 1. I maximized the embedded browser window that displays the authentication page
 2. I switched the language to Polish (my language)
 3. As per the original workaround (which was insufficient on its own in my case), I clicked Next with mouse instead of using Enter

No further problems encountered.

*** Bug 490925 has been marked as a duplicate of this bug. ***

(In reply to Szczepan Hołyszewski from comment #13)
> I just tripped on this, and here's a workaround that worked for me, combined
> from an earlier workaround posted in #485286 and my own experimentation:
> 
>  1. I maximized the embedded browser window that displays the authentication
> page
>  2. I switched the language to Polish (my language)
>  3. As per the original workaround (which was insufficient on its own in my
> case), I clicked Next with mouse instead of using Enter
> 
> No further problems encountered.

This worked for me too, although I did not change the language.

Tokens expiring in Dolphin also. Also cant add Google account in Solus Plasma 6.

(In reply to gabriel.rilling from comment #15)
> (In reply to Szczepan Hołyszewski from comment #13)
> > I just tripped on this, and here's a workaround that worked for me, combined
> > from an earlier workaround posted in #485286 and my own experimentation:
> > 
> >  1. I maximized the embedded browser window that displays the authentication
> > page
> >  2. I switched the language to Polish (my language)
> >  3. As per the original workaround (which was insufficient on its own in my
> > case), I clicked Next with mouse instead of using Enter
> > 
> > No further problems encountered.
> 
> This worked for me too, although I did not change the language.

I've tried this a few times on two separate systems, I don't speak polish and even tried that part specifically but unable to reproduce today.
All items give an error indicating that there is an issue with the browser used for sign or the app setup to allow sign-in.

*** Bug 485286 has been marked as a duplicate of this bug. ***

(In reply to Elvis Angelaccio from comment #18)
> *** Bug 485286 has been marked as a duplicate of this bug. ***

Actually, even this report really looks like a duplicate of #420280

I guess we can close this one as well?

(In reply to Elvis Angelaccio from comment #19)
> (In reply to Elvis Angelaccio from comment #18)
> > *** Bug 485286 has been marked as a duplicate of this bug. ***
> 
> Actually, even this report really looks like a duplicate of #420280
> 
> I guess we can close this one as well?

Like https://bugs.kde.org/show_bug.cgi?id=420280#c105 , I'm facing this bug on Arch with a fairly recent signon-ui version (0.17+20231016), so this may not be the same bug as #420280 which is apparently due to a too old signon-ui version.

Seconded,

I am on signon-ui 0.17+20231016-2 and facing this issue.

(In reply to gabriel.rilling from comment #20)
> (In reply to Elvis Angelaccio from comment #19)
> > (In reply to Elvis Angelaccio from comment #18)
> > > *** Bug 485286 has been marked as a duplicate of this bug. ***
> > 
> > Actually, even this report really looks like a duplicate of #420280
> > 
> > I guess we can close this one as well?
> 
> Like https://bugs.kde.org/show_bug.cgi?id=420280#c105 , I'm facing this bug
> on Arch with a fairly recent signon-ui version (0.17+20231016), so this may
> not be the same bug as #420280 which is apparently due to a too old
> signon-ui version.

Right, I'll rename this report then.

Btw, I cannot reproduce on arch with signon-ui version 0.17+20231016-2

For Gentoo this bug is solved with =>signon-ui-0.15_p20231016-r2

(In reply to Szczepan Hołyszewski from comment #13)
> I just tripped on this, and here's a workaround that worked for me, combined
> from an earlier workaround posted in #485286 and my own experimentation:
> 
>  1. I maximized the embedded browser window that displays the authentication
> page
>  2. I switched the language to Polish (my language)
>  3. As per the original workaround (which was insufficient on its own in my
> case), I clicked Next with mouse instead of using Enter
> 
> No further problems encountered.

Incredibly, it works. Totally nonsensical, but it works.

(In reply to Guido from comment #24)
> Incredibly, it works. Totally nonsensical, but it works.

Okay, this gets me further into the sign on process, where it asks me to verify my Google account on my phone, it then momentarily appears to succeed, then the embedded browser page abruptly clears and switches to say: 

> This app is blocked
> This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access.

When starting systemsettings from the commandline and I run through this process, I get this message:

> org.kde.kaccounts.lib: Error:
> org.kde.kaccounts.lib:   "Access grant not present"

So it seems that this can work when the embedded browser window is made full-screen (which is very weird, and no, I didn't have to change the default language). Regarding making the embedded browser full-screen, if I double-click on the titlebar, then the process will fail like it always does; I have to click the maximize button on the titlebar to have any kind of progress.

Given the error "This app is blocked", maybe this issue is on Google's end?

(In reply to Michael from comment #25)
> Given the error "This app is blocked", maybe this issue is on Google's end?

Yeah, something about what KDE wants to do with the account is tripping some (seemingly newer?) protection on Google's end.

Ideally, KDE should use OAuth2 via the user's default browser instead of opening up an integrated browser that doesn't know any sessions.

See this interesting comment here about contents of `/usr/share/accounts/providers/kde/google.provider`:
https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38

(In reply to Diego from comment #28)
> See this interesting comment here about contents of
> `/usr/share/accounts/providers/kde/google.provider`:
> https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38

Changed provider details to those specified in the linked post used by gnome.  Mine works now.
It seems like the details specified in the google.provider file included by default with KDE are just invalid now.

*** Bug 496600 has been marked as a duplicate of this bug. ***

*** Bug 495192 has been marked as a duplicate of this bug. ***

Now, it is broken on openSUSE Leap 15.6 ; one more time .

The workaround of using the GNOME ClientID and/or replacing/editing the KDE google.provider file with the contents of the GNOME one works for several people - https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38

That suggests to this ignorant peasant that a fix might be straightforward? (Unless it means waiting for Google to provide an updated ClientID).

It's possible to do this without changing a package-owned file. Instead, you can create your own copy of that file in ~/.local/share/accounts/providers/google.provider, and whatever ClientId/ClientSecret you put there will override the one from /usr/share/accounts/providers/kde/google.provider . See discussion at Invent: https://invent.kde.org/network/kaccounts-providers/-/issues/6

You can also create your own client ID, instead of co-opting Gnome's. See the clone instructions for this: https://rclone.org/drive/#making-your-own-client-id

(In reply to devminer from comment #27)
> Ideally, KDE should use OAuth2 via the user's default browser instead of
> opening up an integrated browser that doesn't know any sessions.

I agree, this is what Gnome does since last year: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/139/diffs#e5013ca9537031cc64a62645433ba8c7f51deb1e  It's probably less likely to make Google unhappy. And it's more convenient to the user, since there's a good chance they've already authenticated to Google in their browser.

Here's a discussion from Gnome about Google getting upset about webviews: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/157.

I tried to look into what Gnome did about verification, and didn't really find any equivalent to the recent request to KDE: https://invent.kde.org/network/kio-gdrive/-/issues/1 . Best are:

* Adding a new API key six years ago: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/commit/43a20cfe4d54ddf4fbb9c87996c0beab1b14be75
* Submitting for verification five years ago: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/42

(In reply to Andrés Becerra from comment #23)
> For Gentoo this bug is solved with =>signon-ui-0.15_p20231016-r2

Using Gentoo and signon-ui-0.15_p20231016-r2 installed, but no luck.
Must be other build problem

Hi! 

On OpenSUSE Tumbleweed this doesn't work.. 

No matter if I change the language or maximize the window or use a password or let Google send me a confirmation code - nothing works, I always get 

"This app is blocked." 

Could someone break down the other workaround with gnome online accounts in the necessary steps? 

If I try to install gnome online accounts, zypper demands to pull basically all packages for the full gnome desktop - this is not an option for me (bad experiences with mixed desktop environments!). 

Also, worth mentioning: 

Merkuro Contacts can grab my Google addressbook! 
But kmail cannot be configured to work with the same Google account! 

Thx, p.

(In reply to piedro from comment #38)
> Hi! 
> 
> On OpenSUSE Tumbleweed this doesn't work.. 
> 
> No matter if I change the language or maximize the window or use a password
> or let Google send me a confirmation code - nothing works, I always get 
> 
> "This app is blocked." 
> 
> Could someone break down the other workaround with gnome online accounts in
> the necessary steps? 
> 
> If I try to install gnome online accounts, zypper demands to pull basically
> all packages for the full gnome desktop - this is not an option for me (bad
> experiences with mixed desktop environments!). 
> 
> Also, worth mentioning: 
> 
> Merkuro Contacts can grab my Google addressbook! 
> But kmail cannot be configured to work with the same Google account! 
> 
> Thx, p.

I can confirm that. I use the latest Tumblewed too. Merkuro contacts is ok but I can't connect to Google drive.
Kmail is working for me and I have configured my gmail account without problem.

This is still a problem for me with openSUSE 15.6 Leap with the experimental Plasma 6 repo (version 6.2.5).
Here is the workaround I use: I place the content of the codeblock in this comment https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38 in $HOME/.local/share/accounts/providers/google.provider

Just noticed this bug. Was trying to use google cloud in dolphin since my company requires it, but couldn't login. Guess I will have to look for different options.

(In reply to adamplusplus from comment #40)
> This is still a problem for me with openSUSE 15.6 Leap with the experimental
> Plasma 6 repo (version 6.2.5).
> Here is the workaround I use: I place the content of the codeblock in this
> comment https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38
> in $HOME/.local/share/accounts/providers/google.provider

That workaround worked flawlessly

Created attachment 177337 [details]
Result after login with a Google Account in KDE

A possibly relevant merge request was started @ https://invent.kde.org/network/kaccounts-providers/-/merge_requests/42

The suggested workaround to replace the service provider file works for me to add the Google account to the KDE system settings. 

But my original problem is still the same - I cannot add the Gmail account to Kmail!  

Without the option to add Google Mail accounts, Kmail is pretty much useless as a centra mail management application to handle all mail. 
Which is really sad - I am one of these rare users who really likes Kmail and it's vast functionality and configurability. 

p.

Git commit 1652091be7df65ea16e6eb6d044460c90c19b420 by Nate Graham.
Committed on 14/01/2025 at 20:27.
Pushed by ngraham into branch 'master'.

Google: stop requesting gdrive permission

Google blocked us from using this back in June because we weren't able
justify our API usage to their satisfaction. As such, the permission is
now blocked, and including it here prevents people from logging into
their Google accounts for any other purposes, making 25% of the
KAccounts KCM non-functional. Remove the gdrive permissions for now so
at least other Google things can work (at least in theory).
FIXED-IN: 24.12.2

M  +1    -2    providers/google.provider.in

https://invent.kde.org/network/kaccounts-providers/-/commit/1652091be7df65ea16e6eb6d044460c90c19b420

That's a bummer. I use this extension exclusively for exchanging files with Google Drive ... I'd hardly consider this "RESOLVED FIXED". :-(

What's more, the solution to use the GNOME configuration file at https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38 seems to work fine here, so this isn't even a technical issue, more like a configuration one. Can't we simply use the same line of reasoning to persuade Google to allow KDE access the Google ecosystem as the GNOME guys did? What did they do differently?

This report might be marked as RESOLVED FIXED, but a different bug report should be opened to fix the now missing google drive integration.

Yes, feel free. This bug report is purely about being unable to *add* a Google account. The fact that Google Drive is broken now is a separate (and worse) issue.

JFYI, the solution to use the GNOME configuration file is no solution at all; it's essentially impersonating GNOME and piggypacking on the work they *did* do to retain permission to access Google Drive that KDE wasn't able to do yet. If Google finds out about this, it's likely they'll revoke GNOME's authorization too to prevent others from using it for software that wasn't approved, permanently ban KDE from accessing Google Drive again, or both.

(In reply to Nate Graham from comment #50)
> JFYI, the solution to use the GNOME configuration file is no solution at
> all; it's essentially impersonating GNOME and piggypacking on the work they
> *did* do to retain permission to access Google Drive that KDE wasn't able to
> do yet. If Google finds out about this, it's likely they'll revoke GNOME's
> authorization too to prevent others from using it for software that wasn't
> approved, permanently ban KDE from accessing Google Drive again, or both.

I think the line of reasoning presented isn't "KDE should just steal the gnome config" but more along the lines of GNOME seems to have engaged with google and properly resolved this including the google drive concerns and could we find out who is in charge of managing these APIs/etc and assign this to them so that they can engage with google to properly fix this instead of removing functionality?  

It seems like at that point, we already know the current code itself is sound so any changes made to remove functionality here to make it work now would end up reverted, so would end up just being wasted effort, even if that effort is minimal.

No one is in charge of managing this; KDE is not a company with people assigned to things in that manner.

Most KDE developers minimize their usage of Google services these days, so the overlap between "people who care about Google Drive integration working" and "people who have the interest and time to engage with Google to prove the security of KDE's Google Drive client implementation" is becoming smaller over time. That's the backstory to why this broke, why it's not fixed yet, and why even my exceptionally crude change took so long to get done.

If anyone wants to take initiative to communicate with Google directly on KDE's behalf to prove the security of our Google Drive client, and then also do it again every year when they make us re-certify, and then also do it again randomly when they tighten the requirements again, please let me know and I'll be happy to direct you to the right place.

I use openSUSE Tumbleweed and replacing google privider with Gnome ID is solution for me. It works but Nate Graham has right in his latest comment.

Git commit 78a81aafedced524c1bc9f16788c4304acc3b807 by Nate Graham.
Committed on 16/01/2025 at 14:58.
Pushed by ngraham into branch 'release/24.12'.

Google: stop requesting gdrive permission

Google blocked us from using this back in June because we weren't able
justify our API usage to their satisfaction. As such, the permission is
now blocked, and including it here prevents people from logging into
their Google accounts for any other purposes, making 25% of the
KAccounts KCM non-functional. Remove the gdrive permissions for now so
at least other Google things can work (at least in theory).
FIXED-IN: 24.12.2


(cherry picked from commit 1652091be7df65ea16e6eb6d044460c90c19b420)

Co-authored-by: Nate Graham <nate@kde.org>

M  +1    -2    providers/google.provider.in

https://invent.kde.org/network/kaccounts-providers/-/commit/78a81aafedced524c1bc9f16788c4304acc3b807

(In reply to Roke Julian Lockhart Beedell from comment #55)
> Created attachment 177501 [details]
> Result after login with a Google Account in KDE
This is what's fixed here.


(In reply to Roke Julian Lockhart Beedell from comment #56)
> Created attachment 177502 [details]
> Error in KCM GUI
This is a different issue, typically seen in built-from-source sessions. Not related to this issue.

(In reply to OpenOS-Founder from comment #58)
You'll have more luck asking that at https://discuss.kde.org/new-topic. I don't think this is the place for that.

(In reply to Roke Julian Lockhart Beedell from comment #61)
> (In reply to Nate Graham from comment #57)
> If it's typically from built-in-source sessions, would it be of any use me
> making a report for it? I'm using solely the Fedora 41 RPMs.

If you haven't built Plasma from source, then your issue is caused by a local setup issue or else a distro packaging issue. Either way, let's stop spamming this bug report with it, since 54 people are subscribed and they probably aren't interested in getting emails about unrelated issues.

KMail has its own account system not connected to this, so connection issues there are not related.

Please take any discussion of login issues in KMail elsewhere. Thanks.