CLI V2 returns `-- fields` surrounded in double quotes, V1 didn’t

Options
raybb
raybb
Community Member
in CLI

There is a pretty big breaking change in the CLI V2.
It now returns fields wrapped in double quotes.
Is this intended behavior? Any simple suggestion for getting it back to returning without those quotes?

Here’s a pretty minimally reproducible example:
echo '{ "title": ".env.local2", "category": "SECURE_NOTE", "fields": [ { "id": "notesPlain", "type": "STRING", "purpose": "NOTES", "label": "notesPlain", "value": "NEXT_PUBLIC_ENV=\"DEV\"" } ] }' > template.json

op item create --template template.json
ID: nfuwzcobqgc4gq764nqefk6g2q
Title: .env.local2
Created: now
Updated: now
Favorite: false
Version: 0
Category: SECURE_NOTE
Fields:
notesPlain: NEXT_PUBLIC_ENV="DEV"

op item get .env.local2 --fields notesPlain
"NEXT_PUBLIC_ENV=""DEV"""
op1 get item .env.local2 --fields notesPlain
NEXT_PUBLIC_ENV="DEV"

1Password Version: 2.0.0
Extension Version: Not Provided
OS Version: macOS 12.3

Comments

  • raybb
    raybb
    Community Member
    edited March 2022
    Options

    I found a temporary fix op item get .env.local2 --fields notesPlain | xargs echo

    Edit:
    When you have something in the note like:
    NEXT_PUBLIC_ENV="DEV"
    NEXT_PUBLIC_API_HOST="http://localhost:8000"

    Then the xargs trick doesn't work.

    However this does work:
    op item get .env.local --fields notesPlain --format json | jq '.value' -r

  • Horia.Culea_1P
    Horia.Culea_1P
    Options

    Hey @raybb , thank you for reaching out to us!
    I was able to reproduce this, it seems to be indeed a bug. I've filed an internal issue and will take it up with the team during our next team meeting.
    In the meantime, there is a new command in CLIv2 that allows you retrieving field values in a more native fashion: op read. Did you already get to give it a try? Running op read op://<vault name or ID>/<item name or ID>/notesPlain should retrieve the correct value.
    Let us know if this is helpful for you!
    Best,
    Horia

  • franklin
    franklin
    Community Member
    Options

    Hi, would be great to have that fixed.

    Read is fine but we're loading the whole item and then extract some fields which currently breaks.

  • Horia.Culea_1P
    Horia.Culea_1P
    Options

    We're currently working on this issue, we should be able to push out a fix for this in the next release.
    I'll post a comment in the thread once this gets resolved. Thank you once again for reporting!

  • kevin.l_1P
    kevin.l_1P
    1Password Alumni
    Options

    Hey @raybb @franklin

    We believe that you can achieve the same output behaviour possible with V1 with V2:

    Getting the raw value of a single field

    v1

    op get item <item> --fields <field>

    v2

    op read op://<vault>/<item>/<field>

    Getting multiple values in the csv format

    v1

    op get item <item> --fields <field1>,<field2> --format csv

    v2

    op item get <item> --fields <field1>,<field2>

    Getting values in the json format

    v1

    op get item <item> --fields <field>

    v2

    op item get <item> --fields <field>

  • kevin.l_1P
    kevin.l_1P
    1Password Alumni
    Options

    That being said, we do recognize that the current behaviour may not be what you are looking for and are interested in learning more about your use cases to see where we can improve.

    Could you tell us a bit more about your workflow? Where are you using the values from 1Password? Are you doing manual commands or feeding the output into a script or another workflow?

    @raybb The contents of your notes seem to be a .env format, are you consuming that via a file/library?

    @franklin What data from the items are you using? Do you need just field data or other data as well? Where and how are you consuming the data (via app, script, other)?

  • raybb
    raybb
    Community Member
    Options

    Yes, I use this to generate a .env file when a new user sets up the repo.
    The .env file isn't in version control so it's easier to just generate it on the fly.
    op read op://<vault name or ID>/<item name or ID>/notesPlain works for me.

    I thought about using the file templates tool but it's more work to test and set that up.

  • franklin
    franklin
    Community Member
    Options

    @kevin.li In some cases we store a json String within a field and running

    op item get <item> --fields <field>

    with v2 now returns sth like

    "{""auths"":""bar""}}"

  • mconigliaro
    mconigliaro
    Community Member
    edited April 2022
    Options

    I ran into this because I use op to populate .tfvars files for terraform. Here's my workaround:

    op item get "${OP_ITEM}" --fields label=notesPlain --format json | jq -r '.value' > "${TF_FILENAME}"

    jq returns quoted strings by default for some reason too, but you can use the -r (raw) option to disable that behavior.

  • Horia.Culea_1P
    Horia.Culea_1P
    Options

    @franklin is it feasible for you to run

    op read op://path/to/item-field

    ?

    I mentioned before that we are working on this issue. However, I have recently found out that this is the expected behaviour, and hence I was wrong in considering this a bug.

    For example, assuming a field with value "world":

    The value stored in the field is "world", if that is encoded to CSV as "world", the quotes are lost because the valid way to decode "world" is to world. So the "" are added ("" is the escaped variant of ") to signal that the " are to be decoded and should be in the output.

    Looking forward to hearing from you all about this.

    Best,
    Horia

  • iby
    iby
    Community Member
    Options

    @Horia.Culea_1P I'm using 1password to store a JSON document that I need to be able to simply export like it used to work in v1. Amongst all the great features there's no way of simply having a custom-filed object to simulate JSON – all of them are some kind of credential-bast schemas – none of what I want.

    You have very fancy stuff like database, API credential, etc. but we can't create our own schema from a scratch, i.e., no password fields and such. As the result, the only way around this is to use a secure note. Which used to work just fine until it all got "improved".

    Now I cannot just op item get "${OP_ITEM}" --fields label=notesPlain because apparently "it does the right thing". It doesn't to the right thing for me – that I am very certain of.

    I cannot use op read op://path/to/item-field because my item has spaces and special characters and used in numerous docs and the rest of my 1password items follow a convention. I don't want to mess it up just to compensate for this "new and improved API".

    And the best part I cannot use (or at least find how to use) 1password API to get the bloody item ID to use it with op read op://path/to/item-field where I cannot use special characters…

    I've literally just spent over an hour trying to comprehend these v2 improvements and then double checked if there's an alternative to 1Password because this whole API shinanigans really gets to me for what it's worth.

    **I want to be able to return the flipping item's value AS IT IS! **

    Right now I need to use a completely different tool jq I've no idea who manages it and if it's actually secure or if it has dependencies. Did you even consider this?

    If you want to be smart about this and add quotes, use another format for that, whether it's for CSV or anything else. What I'm getting now is neither human readable or valid or useful.

    Thanks for wasting my morning on this. Massive thumbs down!

This discussion has been closed.