Allow environment to override credential storage mechanism

Bug #737473 reported by Iain Lane on 2011-03-18
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
launchpadlib
Low
Unassigned

Bug Description

Greetings,

I'm wondering if it would be possible to implement support for allowing the
user to force lplib to use credentials_file authentication token storage for
their entire session.

What I'm trying to do currently is use the wrapper in ubuntu-dev-tools in a
script which is running from a cronjob. ubuntu-dev-tools isn't written with
noninteractive use in mind, so its login method doesn't support detached
credentials files. It'd be good if I could just ask lplib to use one without
the u-d-t authors having to implement it themselves.

Something like:

$ export LPLIB_CREDENTIALS_FILE=~/.cache/lplib/blah
# uses this credentials file even though my_cool_script is written using
# login_with without credentials_file
$ ./my_cool_script

would be great.

Do you think this is feasible and reasonable?

Iain

Leonard Richardson (leonardr) wrote :

This seems fine. The behavior in edge cases will be the same as for scripts that specify a credentials_file. In particular, if the token in LPLIB_CREDENTIALS_FILE expires or is revoked, the user will get a browser open and the new credential will be written to LPLIB_CREDENTIALS_FILE.

Which makes me think that we should also test the credentials file for writability *before* the browser open, and raise an exception if it's not writable. "Token in credentials file is bad, but launchpadlib lacks permission to write a new token to that file."

Changed in launchpadlib:
status: New → Triaged
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers