© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
We broke backwards compatibility when we removed the ability to store credentials in an unencrypted store. We did this deliberately, but we didn't consider that a cronjob needs to get credentials without any user input.
I don't think you can completely separate the "load from file" case from the "open a browser" case. You're assuming a file with the credentials already exists. What if it doesn't exist? How does it get created in the first place? You have to open a browser.
Consider a launchpadlib script foo.py. I might run it as a cronjob and you might run it manually every once in a while. The code is the same, but the context is different. Because of this, I don't think it makes sense to have a separate path through login_with() for scripts that are run as cronjobs. You shouldn't have an unencrypted credential lying around on your computer just because I like to run the script as a cronjob on my computer.
I have two ideas:
Idea #1: Let's package a script with launchpad that does the browser open and writes the unencrypted credential to disk. If you need to run launchpadlib cronjobs, you run this script. If you don't, you don't.
---
$ python launchpadlib/
You're about to authorize a Launchpad credential that will be stored *unencrypted* in /home/leonardr/
With this credential in place, you can run cronjobs that use launchpadlib.
But, anyone with access to your computer will be able to access your Launchpad account.
Are you sure you want to do this? [Y/n] Y
The authorization page:
(http://
should be opening in your browser. Use your browser to authorize\nthis program to access Launchpad on your behalf.
Waiting to hear from Launchpad about your decision...
[The browser opens up and I authorize the desktop integration.]
Your unencrypted credential is stored in /home/leonardr/
---
login_with() would check the GNOME keyring, then the KDE wallet, then the encrypted file, then the unencrypted file.
Idea #2: We could change our usage of python-keyring so that if the GNOME Keyring and KDE Wallet are not available, the credential is written to an unencrypted file instead of an encrypted file. This would mean that GUI users get their credential encrypted, and console users don't.
You would still have to run a cronjob script manually, and use a console web browser to set up the credential. (I think there's a bug about console web browsers; we would fix that bug.) But after the first time, you'd never have to do that again for that machine.
I kind of prefer idea #1. "Run this script to set up cron access" is actually simpler than "Run your cron script once manually in a console environment." And console users who aren't interested in setting up cronjobs would still have their credential encrypted.