Current Behavior
If you use op it can remain logged in for multiple command invocations, but if you write a CLI tool with the onepassword-sdk-python you have to re-authenticate every time. If your cli tool has a configuration file where you put onepassword reference strings into it, having the CLI tool subshell to op lets the user stay logged in for a few minutes and not have to re-auth every time they run your command, but with onepassword-sdk-python you have to re-auth on every command.
Desired Behavior
Some sort of auth persistence similar to how op works. My use-case is that every employee has a onepassword account and I want to use their individual onepassword accounts so that I can provision secrets in onepassword and use onepasswords user and group permission management structure, but employees should be able to run a cli command that uses these secrets if they have permission for those secrets.
Benefits & Value
If I subshell to op, then users stay logged in and they can run my command repeatedly, but the performance of looking up, say, 8 secrets is not as fast as using the sdk. If I use the sdk, resolving the secrets is faster, but the users have to re-auth every time. I'd like to combine the auth persistence of op with the lookup performance of the sdk.
Additional information
Compare this program:
import asyncio
import sys
from onepassword.client import Client, DesktopAuth
async def main() -> None:
reference = sys.argv[1]
client = await Client.authenticate(
auth=DesktopAuth(account_name="whatever"),
integration_name="op-read",
integration_version="v1.0.0",
)
print(await client.secrets.resolve(reference))
if __name__ == "__main__":
asyncio.run(main())
to the behavior of op read. If you do op read op://Private/etc/you-get-it twice in a row, you only have to auth once. If you do python op_read.py op://Private/etc/you-get-it twice in a row, you have to auth both times.
What I don't want to do is give people (ok, let's be honest, me) a reason to say "ok I'm going to speed this up" by exfiltrating the secrets into something like a redis docker container.
Current Behavior
If you use
opit can remain logged in for multiple command invocations, but if you write a CLI tool with the onepassword-sdk-python you have to re-authenticate every time. If your cli tool has a configuration file where you put onepassword reference strings into it, having the CLI tool subshell tooplets the user stay logged in for a few minutes and not have to re-auth every time they run your command, but with onepassword-sdk-python you have to re-auth on every command.Desired Behavior
Some sort of auth persistence similar to how
opworks. My use-case is that every employee has a onepassword account and I want to use their individual onepassword accounts so that I can provision secrets in onepassword and use onepasswords user and group permission management structure, but employees should be able to run a cli command that uses these secrets if they have permission for those secrets.Benefits & Value
If I subshell to
op, then users stay logged in and they can run my command repeatedly, but the performance of looking up, say, 8 secrets is not as fast as using the sdk. If I use the sdk, resolving the secrets is faster, but the users have to re-auth every time. I'd like to combine the auth persistence ofopwith the lookup performance of the sdk.Additional information
Compare this program:
to the behavior of
op read. If you doop read op://Private/etc/you-get-ittwice in a row, you only have to auth once. If you dopython op_read.py op://Private/etc/you-get-ittwice in a row, you have to auth both times.What I don't want to do is give people (ok, let's be honest, me) a reason to say "ok I'm going to speed this up" by exfiltrating the secrets into something like a redis docker container.