Bug 330181

Every since I started using 2-step verification at Google, Picasa web album export requires a new application specific password to be generated every time! (unless previous token is still valid)

Reproducible: Always

Steps to Reproduce:
1. Wait a few days for token to expire
2. Start Picasa export plugin

Actual Results:  
1. It asks for password, which is not remembered in kwallet. Username is a long number instead of username.
2. Enter the application specific password (previously copied down manually since it's not remembered)
3. Login still fails!
4. Go to Google accounts, revoke old password, generate new password
5. Come back and enter new password.
6. Now it works. But after the token expires, have to generate a new password again, which is incredibly annoying.

Expected Results:  
Password remembered in kwallet, or at least doesn't have to generate a new password every time.

I found a previous bug #292223, which is closed as fixed without any code change. That's odd because it never worked for me. Note that this only happens with 2-step verification and only if token expired.

Looks like digikam is not alone with this problem. http://lists.yorba.org/pipermail/shotwell/2011-July/002523.html http://redmine.yorba.org/issues/3445

It appears that we're still using the ClientLogin mechanism, which has been deprecated. https://developers.google.com/picasa-web/docs/2.0/developers_guide_protocol#Auth The old mechanism doesn't support newer features like this 2-step verification, refresh tokens, etc. So once token expired, there's no way to get new ones.

I believe they might have assumed you can refresh tokens. So they don't accept the inital app specific password anymore neither. Judging from the experience in shotwell, the only way to fix this is to migrate to the newer oauth, which allows you to keep refreshing the token.

Here's the changeset for this migration in shotwell: https://git.gnome.org/browse/shotwell/commit/?id=b74643f639c35c6bcdb842e38d3eb4c338cd0705

Most of the changes are just different, not really that complicated. But a few things are needed to move forward.

FIrst of all, this requires a client ID and secret. Somebody needs to get one on behalf of this project. (Note that we cannot just "borrow" one from other open source projects. Because oauth do seem to keep track of how many refresh tokens are issued. If user has both clients, we may exceed the limit and one of them will get invalidated. Then we'll have to get new app specific password again.)

Second, oauth requires showing an html page as one of the login steps. This is the hairy part. It requires creating an HTML dialog and hooking up the events to fetch the response. Looks like the Facebook export plugin (also uses oauth) currently just opens the URL and tells the user to copy the text back when it's done. That sounds a bit ugly.

As more and more services are using oauth, it may be time to finally build an oauth dialog, which can go to the common directory and be shared by all the oauth plugins. It's not easy. But it doesn't sound too horribly complicated neither. I found a few resonably simple QT examples on the web:

http://kunalmaemo.blogspot.com/2012/01/posting-on-facebook-wall-from-qt.html
http://www.johanpaul.com/blog/2011/05/oauth2-explained-with-qt-quick/
http://gargidas.blogspot.com/2012/01/facebook-component-in-qml.html

The shotwell commit mentioned previously is another example but in Vala/GTK+.

I've been re-generating passwords almost every month in the past year. If somebody can fix this, that would be great. I've also tried to delete the plugins rc file to make it forget the previous token. Same results. (Cannot get token with the old password and have to generate a new one.)