Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
Former Member
4 years agoCLI feedback
Hi,
I've spent the last couple days working on a 1Password integration into iTerm2. It will be an alternative data source to the mac Keychain that is currently used, but the same GUI for password m...
Former Member
4 years ago
- This has been indeed brought up my multiple customers of the CLI. We're currently investigating the issue and hope to be able to roll out an optimisation soon. In the meantime, please, do let us know if enabling the cache benefits your performance. We have some more ideas to further improve the cache as well, but, for the command you listed, it should help! Let us know if you have any specific suggestions around this feature.
I don't see a big improvement by using --cache. I guess there might be something about the way I run op
that prevents the cache from being effective. I fork and exec a new process each time, setting the OP_SESSION_my environment variable to ensure it's authenticated. Maybe the cache requires the same parent process each time?
- Indeed piping op item list to op item get should be the easiest way to proceed here. I am not sure I fully get the picture though, can you tell me a bit more about your use-case? By ID, do you mean the ID of a field (I am asking since the ID of the item is already within op item list output)? If not, what item details that are not within the list output do you need in your workflow?
op item list
by itself doesn't give user names; otherwise it'd be perfect. My goal is to show this UI:
https://i.imgur.com/bBjZEGw.png
As for ID, I mean the item ID that item list
normally shows. The unique identifier for the item. I need that to edit or delete the item.
- What format would be the easiest to parse for you? We want to make sure the CLI integrates with all the stacks and workflows, so please feel free to let us know, if you have specific suggestions here!
A well-formed JSON document would be fine. Even newline-delimited JSON (http://ndjson.org/) would be better, because then I could parse each line as a separate document and know it would always be correct. So would a custom format specified with --format, although that would probably get pretty hairy to generalize.
- Whenever I need to store the token in a file for testing purposes, I usually do echo $(op signin --raw) > token.txt. Would this help, in your use-case? If not, what would something that would serve your use-case look like? I imagine something like a --output-file flag to the signin command, but I don't want to speculate :)
I basically do this (but I save it in memory). The problem is I don't know what your password prompt says. For example: "Enter the password for mailto:gnachman@gmail.com at my.1password.com". I guess there could be other messages, like if it doesn't know what your email address is, or the host name is not my.1password.com, or if something else goes wrong.
- We are currently looking into adding the ability to pipe json into op item edit, as well as allow passing a --template flag, similar in behaviour to op item create. Would this serve your use-case? How would you envision something more...native looking like? Personally, I could see prompting securely, interactively, for a password and a password confirmation. Do you have any suggestions here?
For my purposes I'd prefer JSON over interactive. echo password | op item set ID
would be good enough for me, but I'm sure it'd be nice to generalize it to other fields as well since you could have non-password values that need to be kept secret. This affects both creating an account as well as changing an existing password.
- Those are indeed the v1 docs, which exist in the developer portal as well. We noticed indeed that this link is currently the one that is accessed from the 'Get started' button of this page: https://1password.com/downloads/command-line/, and this is an oversight that is currently being addressed. Have you noticed this reference anywhere else?
No, nowhere else yet.
- What I do in this scenario is an op user get --me. We currently have, on our backlog, an issue about a command to show the authentication status, something like op status. This is an issue also when biometric unlock is not enabled, so hopefully we'll get two birds with one stone here. What do you think about this?
This works and is better than my hack. Thanks! An extension of op status would be great.
And I'll add an item 10: it'd be great if the CLI were open source. I could get to the bottom of things more easily.
Thanks so much for your help!
-George