Today, I noticed that I wasn't able to create a secure note anymore via the CLI. I found out that I had added a value that contains a = (equals) sign in the value (this is a secret which is base64 encoded and needs to be stored in the secure note).
This is easy to reproduce:
Works:
op create item 'secure note' '{"a":"b"}' --title=caching-secrets --tags=kubecfg --vault=cluster {"uuid":"6j3wgprmlpx7k5xhud3jpnnom4","createdAt":"2021-01-08T11:01:49.9553272+01:00","updatedAt":"2021-01-08T11:01:49.9553273+01:00","vaultUuid":"ub2jqfvvcfcrrv4turjl7phjs4"}
Does not work:
op create item 'secure note' '{"a":"b**=**"}' --title=caching-secrets --tags=kubecfg --vault=cluster [ERROR] 2021/01/08 11:02:28 The item doesn't have a "{\"a\":\"b" field.
Is there any workaround for this? Could you please provide a fixed version?
Thanks, Thomas
1Password Version: 1.8.0 CLI also on 1.6.0
Extension Version: Not Provided
OS Version: Linux (WSL)
Sync Type: Not Provided
Referrer: forum-search:I am using the CLI to create secure notes. Today, I found out that having an = sign in a JSON value
Comments
Team Member
Hello Thomas,
I'm sorry to hear that you're having trouble creating items when the value contains an equals sign. The error message doesn't explain well what the command-line tool is trying to do.
When you are creating an item, you can create the item either using assignment statements or using a 1Password JSON object template.
The assignment statements feature is what is causing the problem here. From
op create item --help
:So when you type:
then the command-line tool parses that out as:
field
=
value
{"a":"b**
=
**"}
which yields the error message:
Fortunately, we have a way around this. You can encode the secure note's contents with base64url encoding, which protects all special characters from being interpreted by the command-line tool.
where I have underscored the part of the command that I changed. Or, if you prefer to write the contents of the secure note in a file called "secure_note.txt", you could use:
I hope that this helps, Thomas. Please feel free to write back with any other questions or clarifications.
Hi Michael,
thanks for responding. I used the encoded format before but when I noticed that it works with plain JSON also I got rid of it. I wasn't sure why this would be needed.
I think I tried it with base64 encoded format too but I will have a look at your proposal and give you feedback as soon as I have tried it.
This way all is working. Thank you very much.
Team Member
Hey @thofmann ,
We're glad to hear it's working for you.
On behalf of Michael, you're most welcome