launchpadlib

Bug #686690
Comment #17

Comment 17 for bug 686690

Revision history for this message

Gary Poster (gary) wrote on 2010-12-14:

#17

Thank you. That looks good.

For clarity, I want to edit two paras. Edits are surrounded by asterisks (where one edit is the addition of an intervening paragraph.

"""
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 *desktop-wide* credential is found, launchpadlib looks for a legacy application-specific credential in ~/.launchpadlib/cache/[site]/credential, and deletes it.

*If an unencrypted desktop integration credential is not found, launchpad looks for a legacy application-specific credential in the path designated by credentials_file, if given; and then in ~/.launchpadlib/cache/[site]/credential . If found, it is used.*

If no cached unencrypted credential is found *in any of the above locations*, 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.
"""

My intervening paragraph above states my opinion on the answer to this issue: """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.""" IOW, I think application-specific credentials should be used, for backwards compatibility.

A corollary for all of this is that I don't think the old per-application authorization code can ever go away entirely--we'll always need to be able to read them, even though we no longer write them.

I think the end of #1 ("But") was probably going to mention that the keyring might issue a challenge, and we never want that for non-interactive (cron-like) scripts.

Thank you.  That looks good.

For clarity, I want to edit two paras.  Edits are surrounded by asterisks (where one edit is the addition of an intervening paragraph.

My intervening paragraph above states my opinion on the answer to this issue: """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."""  IOW, I think application-specific credentials should be used, for backwards compatibility.

A corollary for all of this is that I don't think the old per-application authorization code can ever go away entirely--we'll always need to be able to read them, even though we no longer write them.

I think the end of #1 ("But") was probably going to mention that the keyring might issue a challenge, and we never want that for non-interactive (cron-like) scripts.