[12] How do I obtain a totp value

@rknshia good to hear that it worked!

maybe we could give the --otp flag an optional value with the name of the field?

That's awesome that you mention that, I've already brought that up with the team and we will be continuing to discuss it.

Appreciate the feedback!

@"Justin.Yoon_1P" thanks a lot, that seems to work! As a suggestion for retrieving other totp fields, maybe we could give the --otp flag an optional value with the name of the field? I feel like that kind of strays away from the --field/fields flag though, so maybe there's a better way you're already looking into :)

Hello @MichaelKloske , MrC , ramblingpolak , @rknshia !

It's been a while - but we wanted to let you folks know that we've introduced a way to easily retrieve the primary totp for an item, it works exactly like how op get totp used to work in v1 but the new command is: op item get --totp.

Hopefully this command works for you, and please do note that we are still investigating how to retrieve specific totp fields' otp values (and not just the primary totp field's) at the moment as well.

I would also like to see an option back like before. If possible I'd like to not use additional tools like jq to get the totp.

If retrieving a totp field with "--fields" directly I'd be fine with always returning the totp value (and not secret like right now), I don't think I ever wrote a script that needed the totp secret - but there's probably others that do.

I'll I liked the simplicity of the get totp command but am currently using op item get <item> --field type=otp --format json | jq -r .totp as per the 2.0 Upgrade guide (note --format json which is required but not mentioned in the upgrade guide)

@MichaelKloske Thank you for that feedback, given that - perhaps getting rid of the op get totp <ITEM> was not the best idea.

I'll bring it up with the team to consider bringing it back, highlighting the ease of use of the old command.

My problem with all those solutions is, that I have just a bash script but I don't know the name of the OTP-field. I just know, there is only one and this is the one I need to use for my doings. Therefore the --fields - options does not have any use for me. In each case I would have to parse the output of op item get for an OTP field and its name to use that. But grepping for the line with totp: is also okay for me.

As long as op item get provides the raw otp value I need for my doings everything is fine for me.

But anyway if you know the field name than the raw OTP-value is probably the information of interest and not the URL were the user can retrieve somehow the value.

Hey MrC

We did consider the approach using a separate flag to get the totp value, but hesitated to implement it for the sake of simplicity. I think hearing your opinion in support for such flags gives the approach a bit more weight. We will take that approach into consideration and thank you for the feedback :)

You could add a syntax to retrieve "raw" (or uninterpreted) values to your --fields option, or support an alternate version, such as --fieldsraw.

This gives the CLI users access to both forms - raw TOTP secret, raw Unix epoch dates, or any other input value where 1Password displays it after some transformation, and 1Password-transformed values by default.

Hey @MichaelKloske ,

We are currently torn whether or not op item get <MyItem> --fields <SomeTotpField> should be returning the totp secret, or totp value.

Currently when a totpField is specified in the --fields flag, the totp secret will be printed. However, we are considering changing it to return the totp value instead.

This would allow users to use op item get <MyItem> --fields <aTotpField> to retrieve just the totp value, and set it to a variable, or pipe it into commands that require the totp code.

The tradeoff here is that it would be hard to isolate just the totp secret, but given the use cases with totp values far exceeding those with totp secrets, we think that that this is a good tradeoff. The totp secret would still be accessible by retrieving the whole item, and processing it via jq or other similar methods if isolating that secret is necessary.

We are interested in what your thoughts are here!