Created attachment 139947 [details] resource forbidden error in "drives-example" SUMMARY I am no longer able to access my GDrive via kio-gdrive and libkgapi using the built-in credentials (client ID 554041944266). When I go through kio-gdrive and try to add a new account, I'm taken to the "App blocked" page (using qtkeychain, but even with libkgapi 20.11.80 which already opens the auth page in my webbrowser). STEPS TO REPRODUCE 1. Build kio-gdrive against qtkeychain, install (and libkgapi 20.11.80 or *presumably* newer) 2. run `dolphin gdrive:` 3. click "New account" 4. Find the auth. page in your browser, pick an account or authenticate to give access to "Akonadi Resources for Google Services" OBSERVED RESULT "This app is blocked This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access." EXPECTED RESULT The next step in the auth. process I CAN get beyond that step using my own Google Cloud client ID,secret pair to a project in which I configured Google Drive API access. Afterwards, I can quit dolphin and restart it again and still have direct access to my Google Drive, but when I try again some time later I have to jump through the authentication again, pretending to create a new account. ADDITIONAL INFORMATION Using the drives-example test from libkgapi's examples I do get past the authentication, but the app window shows no content. Clicking "Get Drive List" then gives me the attached "resource forbidden" message that suggests that the Google Drive APIs haven't been configured or sanctioned yet. It also suggests a subtle difference in the authentication procedures used by kio-gdrive's keychainaccountmanage.
Actually, it would seem that I need to re-authenticate each time the kwallet has been closed. Does that mean some crucial information is not being stored there?!
Restarting kdeinit5 from a terminal gives me some useful output (finally). I'm seeing org.kde.kgapi: Unauthorized. Access token has expired or is invalid. but also kf5.kio.core: error() called twice! Please fix the "kio_gdrive" KIO slave kf5.kio.core: UDSEntry for '.' not found, creating a default one. Please fix the "kio_gdrive" KIO slave
So.... Turns out that keychainaccountmanager.cpp wasn't updated to use the proper Google credentials for KDE!
Also, kaccnt-providers-git/providers/google.provider.in has the following: ``` <setting name="AuthPath">o/oauth2/auth?access_type=offline&approval_prompt=force</setting> <setting name="TokenPath">o/oauth2/token</setting> <setting name="RedirectUri">http://localhost/oauth2callback</setting> <!-- HACK: access_type is non standard, but Google requires it in order to return a refresh token --> ``` Shouldn't libkgapi be updated to include the access_type and approval_prompt query items in its authentication request?
Patches welcome I suppose.
Back in 2019 I tried to request new API keys for the qtkeychain backend, butI got fed up by Google bureaucracy and gave up. I think we should really drop the qtkeychain backend since it's been broken for years now. The KAccounts backend is the way to go.
Not broken, just not updated. At least, that was the case in July 2021. I've had it working for some time since but it seems something may have changed yet again.
Git commit 6d7456fde9762bf76007388d17b7367b20160ac4 by Elvis Angelaccio. Committed on 30/10/2022 at 11:14. Pushed by elvisangelaccio into branch 'master'. Update Google Drive credentials for qtkeychain backend These credentials were created back in Akademy 2019 but were never shipped because Google never verified the "OAuth consent screen" shown to the users. (I never understood if Google didn't like something or if simply no one at Google looked at it). However, these credentials do work if you go in the "advanced" section of the oauth screen and click on the "I trust KDE e.V. as developer" button. So I think is better to ship them anyway, rather than ship the old credentials that have been broken for years. The qtkeychain backend is disabled by default anyway and is only a fallback for those who don't want to use the main KAccounts backend, which is the recommended one. CCMAIL: kde-ev-board@kde.org M +2 -2 src/keychainaccountmanager.cpp https://invent.kde.org/network/kio-gdrive/commit/6d7456fde9762bf76007388d17b7367b20160ac4
(In reply to Elvis Angelaccio from comment #6) > Back in 2019 I tried to request new API keys for the qtkeychain backend, > butI got fed up by Google bureaucracy and gave up. > > I think we should really drop the qtkeychain backend since it's been broken > for years now. The KAccounts backend is the way to go. I pushed these keys to master. They do work as long as you click the "I trust KDE e.V. as developer" button in the google auth screen. Not ideal but I think it's better than shipping the old credentials that have been broken for years.
Thanks Elvis. This seems better indeed. Does the UI guide the user in the direction of clicking that checkbox, so they can figure it out?
Created attachment 153390 [details] screens of google oauth window
(In reply to Nate Graham from comment #10) > Thanks Elvis. This seems better indeed. Does the UI guide the user in the > direction of clicking that checkbox, so they can figure it out? I attached a zip with some screenshots, so that you can have an idea. Basically you need to click "Advanced" and then click to "Go to KDE KIO Worker...". Given that you need to self-compile kio-gdrive and explicitly disable the recommended KAccounts backend in order to get to this screen, I think it's not too bad. I'm not aware of any distributions that disables the KAccounts backend, or we would have received a lot more bug reports :)
All right, that seems fine. Thanks again!