v2.0 "Client ID" and "Client Secret" are not saved
Brought to you by:
drdi
Menu
▾
▴
Setup of v2.0 did work - Sync is working, but only once.
Then "Client ID" and "Client secret" are empty again and once entered again, I also have to re-confirm the "Google Sync Plugin Authorization".
What is wrong?
Is the correct Google Account preselected when you open the configuration dialogue again?
In any case you should try to upload or sync after initial configuration. If you try to download instead, your local database will be overwritten. The plugin stores the configuration (Client ID, Client Secret) in the database. If you download, that will be overwritten too.
Once the configuration is also in the remote version, you can of course use "download".
Try opening the configuration dialogue manually (from the menu) and have a look at the password entry (Google Account) you selected after closing the configuration dialogue (with correct values of course).
In the advanced tab there should be at least 2 string fields. One for the Client ID and one for the Client Secret. The names are "GoogleSync.ClientID" and "GoogleSync.ClientSecret". After authorization there should also be "GoogleSync.RefreshToken".
Last edit: Uranium235 2014-11-14
Thanks for the answer - I found the reason:
I deleted existing "GoogleSync.RefreshToken" in the advance-tab - and now it works.
I hope the sync on my other computers using sync v1.6 is still working ...
thanks
That is strange. Whenever the plugin encounters an invalid Refresh Token it does ask for authorization again as if there was no token to begin with. But once new authorization is given successfully, that new token should be saved and everything working fine thereafter (unless using "download" in that case).
So simply deleting the existing token should not have made a difference.
With an Invalid Client ID or Secret it should fail with an error and not even work once.
If you can, could you try and replicate the Problem? If there is a case that the Plugin does not handle properly, I would like to fix it.
Other computers using v1.6 should not be affected. But if you followed the instructions for upgrading and revoked authorization for security reasons, they will need to be authorized again.
You should also make sure they don't overwrite the remote database with a version that misses those 3 string values though or the new version will lose it's authorization / configuration the next time you sync.
You should upgrade them to v2.0. It may be that authorizations (Refresh Tokens) become invalid after a while if using (two) different Refresh Tokens, which definitely is the case when mixing versions. Ideally there should only be one active for a combination of Client ID / Client Secret and Google Account for the Plugin. The new version ensures that by storing that/those values inside the database.
Last edit: Uranium235 2014-11-14
Hi,
Thanks for your work!
I had the same problem and was asked by GoogleSynkPlugin to input credentials into authentication screen every time I tried to synchronize. At the same time synchronizations resulted in no warnings, etc.
The problem was fixed when I had uploaded (not sync.) my database using the Plugin.
I have fixed a related issue in the upcoming release. Maybe that was also the problem here. I will do some more test though trying to replicate the problem.
Did you configure the Plugin manually via the Tools menu or did you wait for the Plugin to ask for a configuration automatically when you tried to sync and it didn't remember the authentication for the next time?
Last edit: Uranium235 2014-11-27
Never mind. I found the problem.
The problem is that KeePass does not automatically change the modification time of an entry when a new Plugin config (or authentication) is saved with that entry.
Due to the way the KeePass synchronization works, the remote version with the old config overwrites the locally just updated config when using the sync command, thus discarding the most recent authentication (refresh token).
Fixed with the upcoming 2.1 release.
The reason does matter. Thanks for your work again! Waiting upcoming releases.
You might want to clearly state a workaround on your project page until you can release 2.1. It took a bit of digging to find this thread.
BTW, a simple workaround is making a change to the Google Account entry in KeePass-- any change at all-- and it will update the timestamp for the entry, and thus save it properly.
One change would be adding another Advanced property, or deleting an existing Refresh Token entry. Just be sure not to delete something important!
My problem is that when I go to sync the on-board kdbx file with Google Drive, I can get the TOTP accepted and the update completed, but I cannot get an OAuth Refresh Token issued. On 11/2/14, I upgraded KeePass from v2.27 to v2.28, KPScript from v2.27 to v2.28 and Google Sync Plugin from v1.6 to 2.0. KeePassHttp is at v1.8.3.0 and chromeIPass is at v2.67. I have checked the credentials against Google Developers Console and they appear to be correct. The Newtonsoft.Json.Net35.dll files seem to be in order.
In Program Files, KeePass.config.xml, PreferUserConfiguration is true. Since this appeared to be a major update for Google Sync, in all three KeePass.config.xmls, I deleted the Custom\Items pertaining to Google Sync. And in Google Account Permissions, I revoked access for KeePass but it has access now. In the two user AppData KeePass.config.xmls, all of the Items were recreated. In the Program Files copy, GoogleSyncAutoSync and GoogleSyncAccountUUID were not created, so I copied and pasted them and filled in the latter. I also changed GoogleSyncAuthenticationForm to true in all three.
Then I clicked Tools\Google Sync Plugin\Sync with Google Drive. On Google Sync Plugin Configuration, Google Account and KeePass UUID are already properly filled-in. I copied and pasted in Client ID and Client Secret. “Auto Synchronize Database on Save” is blank. Next, I clicked OK. The message, Google Sync Plugin Authorization: “KeePass would like to-” opened and I clicked Accept. After that, I received notification that sync had been completed and the file on Google Drive had been updated. Then when I repeated the procedure, it was necessary to repeat every step, exactly as I described above.
On my Windows Vista computers, I have two user accounts, one in the Administrators group and one in the Users group. In both accounts, I deleted the AppData\Local\Dominik_Reichel folder and a replacement was not created. In the Users group account, I manually created a virgin Dominik_Reichel folder and a Refresh Token was not entered, nor was user.config ever accessed. KeePassHttp and chromeIPass are functioning better than ever.
Sorry, but I'm not sure I follow.
The Plugin v2.0 does not care about PreferUserConfiguration. Nothing has changed in that regard. The only two Plugin settings that are saved outside the database are now "GoogleSync.AccountUUID" and "GoogleSync.AutoSync".
Those values could be coming from a global or local KeePass config, depending on your settings (either or, not a mix).
The rest (OAuth stuff) is saved inside the database with the password entry pointed to by "GoogleSync.AccountUUID", which is set by the config dialog (drop down or custom).
There should be no replacement for the AppData\Local\Dominik_Reichel folder (or rather the user.config file inside), that was the whole point of moving the location of that setting inside the database (the refresh token).
You most likely have the same issue as the other two above. That issue will be fixed with the next release.
In the meantime, make sure you use "upload" the first time you use the plugin instead of "sync" or "download". If using multiple computers, you should manually download the database from the Google Drive to them after the very first use of the new Plugin by using upload (with the 1st machine and use).
All those other computers need then is for you to select the correct account when they are used for the first time (because that setting is in the KeePass config). The correct OAuth credentials should be filled in automatically, as the plugin found them inside the database.
Last edit: Uranium235 2014-11-29