Comment 16 for bug 686690

OK, I've talked to Gary. Here's my new proposal.

1. The existing login_with method will become the method of choice for scripts that are, or *might be*, run as cronjobs. This method will never access the keyring, even to check for cached credentials.

When you call login_with, launchpadlib looks for a desktop integration credential in ~/.cache/launchpadlib/[site].credential (or in the path designated by credentials_file). If a cached unencrypted credential is found, launchpadlib looks for a legacy application-specific credential in ~/.launchpadlib/cache/[site]/credential, and deletes it.

If no cached unencrypted credential is found, launchpadlib does a browser open asking for a desktop integration credential. The Launchpad URL also includes the query string value "show_unencrypted_warning=true". Because of this, the Launchpad page that asks you to authorize the token, also mentions that a credential will be stored unencrypted on your hard drive, allowing you to run applications from cron scripts.

Once the desktop integration credential is authorized, it's written unencrypted to ~/.cache/launchpadlib/[site].credential (or the path designated by credentials_file).

I don't have an opinion on what should happen if credentials_file designates a application-specific credential. Either the application-specific credential should be used, or a browser open should happen and credentials_file should be overwritten with a site-wide credential.

We can alias login_with to "login_without_user_input" or something, and encourage developers to migrate to the new name. This name is a bit of a misnomer, because if there is no credential you will still get a browser open. But

2. A new method will be created for applications that will never be run as a cronjob. I would like to call this method just plain "login", but we could call it "login_for_interactive" or something like that. This method will use the keyring exclusively, or almost exclusively.

login() does not recognize the credentials_file argument.

When you call login(), then maybe launchpadlib looks for a desktop integration credential in ~/.cache/launchpadlib/[site].credential, or maybe it doesn't. It doesn't matter much to me, but if there's an unencrypted credential lying around we might as well use it.

Either way, the next step is to ask python-keyring for a cached credential. (This may require user input to unlock the keyring.)

If a cached credential is found, login() looks for a legacy application-specific credential in ~/.launchpadlib/cache/[site]/credential, and deletes it, just like login_with() does.

If there is no cached credential, login() does a browser open, just like login_with() does. However, it does not put "show_unencrypted_warning=true" in the query string, so Launchpad doesn't give the warning about unencrypted storage.

Once the desktop integration credential is authorized, it's stored in the GNOME keyring (or python-keyring equivalent).

3. As soon as this is implemented, we'll go to the authors of Ground Control, Apport, etc. and help them port their code to use login() instead of login_with(). (Or whatever hacks they might have written instead of using login_with().