Keeweb: Cookie issue with Gdrive after changing Google password

[jlundan]

Hey!

Thanks for the outstanding application! Finally something proper to use with my Keepass DB on Linux!

Just wanted to drop you a note that run into a weird issue with Google Oauth and cookies. Went a bit like this:

1. I started KeeWeb and opened my kdbx file from Google Drive. Everything went fine, the Oauth dialog popped up, I logged in (using 2-factor auth on my phone) and gave access to KeeWeb to my files. After that the Oauth popup closed, I entered my kdbx password and the file opened.
2. While KeeWeb was open, I changed my Google password from Google's account page on the same machine (using my standalone Chrome). I selected to keep me logged in on the machine I was changing the password (Google gave me that option).
3. After that, I could save my kdbx file using KeeWeb to Google Drive (the same file I opened in step 1).
4. However, after about 10 minutes or so, KeeWeb suddenly popped up the Oauth dialog again. This time when I logged in, the dialog complained that I had a problem with cookies (showed help page how to clear or enable cookies. I think the html on that page came from Google, so it was probably a generic help page rendered inside the oauth login window). Don't have screenshot about it unfortunately.
5. I restarted KeeWeb, opened the file again from Google Drive (exactly like I did in step 1), and the same error from step 4. came up again. The Oauth popup would not close by itself, it just displayed that cookie error message (I had to close the popup myself since there was nothing to do in the dialog itself).

I ended up clearing cookies via the developer tools in KeeWeb but that did not help. Reinstalling KeeWeb did not help either. What did help was deleting the KeeWeb directory under my home folder (~/.config/KeeWeb on Ubuntu 16.04 LTS)

KeeWeb version was KeeWeb-1.6.3.linux.x64. I installed from the deb file available on keeweb.info.

My user agent info was:
KeeWeb v1.6.3 (cded8a4, 2017-12-11)
Environment: electron v1.7.9
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) KeeWeb/1.6.3 Chrome/58.0.3029.110 Electron/1.7.9 Safari/537.36

There was no logs about this during the Oauth process. Just log entry about opening the Oauth Popup and another after I closed it.

Maybe there is something left dangling in the KeeWeb config folder related to Oauth/cookies which makes the Oauth dialog fail after the Google password is changed while KeeWeb is running. I know this not exactly most informative bug report, but perhaps enough info for a short FAQ item: just to let people know that deleting the KeeWeb config directory helps if people run into weird Google Drive Oauth cookie issues.

Cheers,
Juha

[antelle]

Thanks for the detailed description!
I'll check what can be done, probably some cookies are not deleted or something like this.

[miyagui]

Had the same problem on Windows and Dropbox. Had to delete the whole %APPDATA%/KeeWeb folder for it to reset back to normal.

[antelle]

@miyagui how to repeat it with Dropbox? I'm using it for several weeks without problems.
Cookies are stored in this folder, right. Specifically, in runtime-data.json, you can delete only this file.

[miyagui]

I was doing my annual windows format and overall cleanup. I had been using keeweb for almost a year on this OS before the format without any problem. Manual copy and paste from the wallet no browser connector. I'll leave some ideas of how to replicate the error. It's the second time it has happened to me already though the last time it was on ubuntu.

• On keeweb I'm working with the "full dropbox" option and a custom folder.
• I logged in with my dropbox account everything was working fine. Even after multiple restarts.
• I didn't change my password like @jlundan but I cleaned up my db folder in dropbox from the web gui. I just left my dbbx file in it. There used be some other files in it. Also I deleted an old Apps/Keeweb db I had from a previous install.
• Installed the keeweb http connector plugin as well as the firefox extension.
• I was going to give the api a try and left the option activated for a while, didn't succeed though.

The next day I turned on the PC but there was no saved database path. I tried to login with my dropbox account (I was already logged in on firefox 57). The oauth popup kept reappearing without any visible error.
I reinstalled keeweb but got the same problem. Noticed that some old configuration was loaded as well even after the new install. I realized that there had to be some data files lying around and ended up in the %APPDATA%/Keeweb folder. Changed the name of the folder (for safekeeping) and it worked.

I hope it's helpful.
I'll be monitoring this threat in case you need some other input.

[antelle]

@miyagui which error did you get in Dropbox?
From what I understood, in the original issue report about Google it was some Google-specific cookie message (but it could be something ours).

[miyagui]

No error at all but most likely a cookie corruption. The login popup (login and password) would keep appearing with no visible error at all.
After deleting the keeweb AppData folder it didn't ask for my login or password. Since I was logged in on my browser, dropbox asked for permission for the app which is standard procedure.

cookies are stored in: %APPDATA%/keeweb/temp/[number]/Cookies

[antelle]

Interesting, thanks, I'll try to repeat.
Everything from temp is deleted on next start (to prevent unwanted chromium runtime modifications by other apps), cookies are stored in runtime-data.json, cookies field. This was changed in v1.6, previously cookies were managed by Chromium, so it could cause these issues.

[miyagui]

I'm not sure if this is connected but since it's a fresh install of windows I had some trouble with my clock. I'm at UTC-5. I have a dual boot with ubuntu and win10. Windows treats the system clock (bios) as local time. Ubuntu on the other hand treats the system clock as UTC. I have my bios clock set to UTC. So windows clock would always be +5 after each restart (I'd see it on the login screen) and after a while the OS would change it back to normal after syncing with their own NTP servers. Ex: It's 10:00 here. Bios is set to 15:00. Ubuntu would show 10:00 by using UTC-5 (which is correct). Windows would show 15:00 by default (thinking it's local time). I recently changed the Windows clock to use the system clock as UTC to fix that problem.

As I said I'm not sure if it's connected but it could be the culprit since those files are re-populated on start and as so could get corrupted because of the incorrect clock. Just making sure you got all your bases filled, I hope you are able to find the culprit.

[meGAmeS1]

Hi, thanks to @antelle I managed to solved this issue by deleting all cookies in the array in the json file runtime-data.json (located at ~/Library/Application Support/KeeWeb/runtime-data.json on macOS). I just had to log back once after relaunching KeeWeb and it was all good.

The page I had about the cookie problem reported by Google was this one. I'm running KeeWeb 1.6.3 on macOS 10.13.1. I might have changed my password of my account too few weeks ago, so that might have caused the issue, but I'm not sure if I had already installed KeeWeb by that time.

Anyway, for now it seems to be solved

[antelle]

So, it's definitely related to the password change, @meGAmeS1, thanks again for checking, I'll test this case.

[meGAmeS1]

Hi again. Just to add up some more feedback, my colleague showed me this afternoon he had the same issue. And he definitely didn't change his password (for me as I said, I wasn't sure if I had already installed KeeWeb by the time I changed my password). He is also on macOS with the latest KeeWeb version. I did clean the cookies from runtime-data.json and it fixed it too.

In both of our cases, the issue is very recent (like since January 1st), so I'm not sure of what the root cause is, but I hope in some way it helps you

Edit: Just a detail, my password change was like a month ago, and I had used KeeWeb by that time without any issue.

[ginkel]

AFAICS the fix by cleaning runtime-data.json is only temporary and needs to be repeated once the session with Google expires again.

[ttimmons]

I'm having this same issue as well. However my issue was not related to a password change, it seems like it occurred once the session with Google expired.

However the solution provided by @meGAmeS1 (clean the cookies from runtime-data.json) seemed to fix it for now.

[antelle]

This will indeed fix it, but temporarily. Normal fix will be released in the next version.

[UnsignedLong]

To make this work-around a bit easier until this bug is fixed:
sed -i .bak 's/"cookies":\[.*\]/"cookies":[]/g' ~/Library/Application\ Support/KeeWeb/runtime-data.json

[ffflorian]

Thanks for the work-around @UnsignedLong! Here is the version for Linux users using GNU's sed (Debian, Ubuntu, etc.):

sed -i.bak 's/\("cookies":\)\[.*\]/\1[]/g' ~/.config/KeeWeb/runtime-data.json

[dzek69]

This happens very often to me, as I'm using my Google account just everywhere (phone, few browsers, few Electron-based apps, so new session is needed for every of them and KeeWeb with GDrive sync of course) and Google forces me to re-login very often because of that I think.

It's not related to password change, as someone stated before, but to session expiration, which can be forced by pass change I guess.

[iopsthecloud]

I have the same issue since my switch to Google Drive File Stream with MacOSX

[jhiemer]

Guys, this bug is really driving me nuts. When will this be fixed?

[dbauszus-glx]

@ffflorian thanks for that. I need this command about once a week, usually more often.

@jhiemer totally agree. this is very annoying.

[ceres-c]

Never had this problem before I changed the password, when I did I faced it and it looks like it was solved deleting ~/.config/KeeWeb/runtime-data.json. BTW I have also unlinked KeeWeb from the apps connected to my account.
YMMV, as it is obvious reading this topic

For reference:
Manjaro linux
keeweb-desktop-bin from AUR

[Coises]

Antelle, might it be wise to add a Clear Cookies button to the Advanced section of General Settings?

I’m not suggesting that as an actual fix for this issue; but consider that browsers always have a way to clear cookies, because unexpected things happen. Whether it’s this issue or something else unforeseen, being able to reset any garbage that might have collected without having to go fishing about in app-specific files seems like it could be a worthwhile option to have.

[antelle]

@Coises we shouldn't. Cookies must just work, without a need to do something with them. What we need here, is properly save them. Most likely this doesn't happen during ajax requests, but this needs checking. Apart from this, I don't see any case when clearing cookies might help. When someone wants to dig deep, it's ok to edit the config.

[antelle]

I've pushed a fix, but I'm not sure if this works, it needs testing.

[Coises]

I can’t yet confirm a lot one way or the other, but one thing consistently does not work. Perhaps this is a useful data point. Using develop including 62efa58 on Windows 7:

• On the select database page, click More, click Google Drive, sign in, select and open a file.

• Lock the file. Click More, click Settings, uncheck Google Drive.

• Quit KeeWeb.

• Launch KeeWeb. Click More, click Settings, check Google Drive, click return to app.

• Click Google Drive. A Google sign-in window asks you to choose an account; the options are the account you signed into before and Use another account.

• Click Use another account and sign into a different Google account.

• The We’ve detected a problem with your cookie settings. page appears. The only ways I’ve found to get rid of it are:

  • Quit KeeWeb, launch KeeWeb again, go to Google Drive and choose the original Google account.

  • Quit KeeWeb, delete the runtime-data.json file, launch KeeWeb again. Now when you go to Google Drive it no longer lists any accounts, and you can sign into whatever account you like.

Edit: Is there any way to turn on development tools for the OAuth popup window? It sure looks like whatever is going wrong is going wrong there; but as far as I can tell, none of what’s happening in that window is reflected in the development tools on the main window.

[antelle]

@Coises that's another thing, thanks, I'll fix it.
OAuth popup devtools can be opened only from code, with openDevTools method.

[antelle]

Please check if it's fixed now. The fix is released, but I don't have a possibility to check it because it doesn't repeat for me.

[vint2k]

@antelle v1.7.1 has the same bug

[jerrac]

After upgrading to 1.7.1 from 1.6.3, on Ubuntu 18.04, I tried opening a new file from Google Drive. The dialog asked me to choose an account, I chose the one I had previously signed in with, then entered my password. Right after that the "We've detected a problem with your cookie settings." message appeared.

After that I exited the program, and moved the ~/.config/KeeWeb/runtime-data.json file to another directory. After opening KeeWeb again, I tried opening a new Google Drive file. Unfortunately, after successfully logging into Google, the dialog did not close. Instead it just loaded the KeeWeb app into the login dialog window. Closing that window and clicking the Google Drive icon again in the main window just opened the app in the dialog window. Trying to open a GD file from the icon in the dialog window opened a new window with a 400 error from google.

I get the same behavior after moving the entire ~/.config/KeeWeb directory to another location.

[antelle]

Ok, thanks for checking, reopened it

[vint2k]

@antelle v1.5.6 is the last version where cookie updater works well

[antelle]

Indeed, after it cookie management was changed and now we need understand wtf and fix it.

[jerrac]

FYI, I created a new Ubuntu vm and ran into the same issue after a clean install of 1.7.1.

I also thought it might have something to do with using a .edu GSuite account vs. a normal Google account. But my normal google account had the same issue.

[antelle]

I just managed to repeat it as well. So, the problem is that when we set cookies in Electron, it keeps them for some reason and when a new cookie arrives from a server, it's not replaced, but added. As a result, two cookies with the same name are sent in next requests and it makes Google sad (for a reason).
To be honest, I don't know how to fix it, some hacking required. I'll try to reproduce it on a clean app, maybe it's something in KeeWeb, not electron.

[antelle]

I've submitted an electron issue, let's see what they reply: https://github.com/electron/electron/issues/16292

[antelle]

Next version should have this fixed

[antelle]

Please check if it works now.

⚠️
There's no need to remove cookies from runtime-data.json now, because they're not stored there anymore. They will disappear automatically from this file after some time.

[jerrac]

1.7.2 worked for me! Thanks!

[dbauszus-glx]

Works for me as well on Ubuntu 16.04 with 1.7.3!

1.7.2 did not work for me.