Onepassword v2 Lookup Plugin is Case Sensitive

[bitjip]

Summary

I try to do a lookup to a 1Password field, but because the Onepassword v2 plugin is case sensitive it cannot find the password from the field.

See: https://github.com/ansible-collections/community.general/blob/c604cc5ba901574697b99bd31236d99e0e6cd1a3/plugins/lookup/onepassword.py#L453

Issue Type

Bug Report

Component Name

onepassword

Ansible Version

ansible [core 2.13.4]
  config file = /Users/jip/Ansible/servers/[REMOVED]/ansible.cfg
  configured module search path = ['/Users/jip/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.9/site-packages/ansible
  ansible collection location = /Users/jip/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.9.12 (main, Mar 26 2022, 15:52:10) [Clang 13.0.0 (clang-1300.0.29.30)]
  jinja version = 3.1.2
  libyaml = True

Community.general Version

Collection        Version
----------------- -------
community.general 6.3.0

Configuration

No response

OS / Environment

Mac OS 12.4 x86

Steps to Reproduce

password: "{{ lookup('community.general.onepassword', 'password_item', vault='password_vault', field='password', section='section name') }}"

Expected Results

I expect that the field password in the section section name get the password from 1Password which has the field name Password and the section name Section Name.

Actual Results

The lookup returns an empty string.

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/onepassword_info.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @Rylon click here for bot help

[ansibullbot]

Files identified in the description:

• plugins/lookup/onepassword.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @azenk @samdoran @scottsb click here for bot help

[rembart]

+1

[felixfontein]

I'm not sure why this should be a bug. The lookup does not claim to be case-insensitive w.r.t. section and field name. So this looks more like a feature request to me?

(This might simply be a expectation mismatch as well because other 1Password tools are case insensitive. I don't know whether you can add two different sections which only differ by casing, or two different fields that differ only by casing.)

[samdoran]

It seems like an expectation mismatch which could be interpreted as a bug. I think it would be good to make the field name matching case insensitive since the items created in 1Password may be either "Password" or "password".

[felixfontein]

Is the field name selected by the user? I'm wondering why it's sometimes password and sometimes Password. If it is determined by the user, is it possible to add both a password and a Password field to the same entry?

[samdoran]

1Password creates the field, but the user can change it. I'm thinking that may older versions of 1Password created items with a 'Password' label, but I'm not sure.

If it is determined by the user, is it possible to add both a password and a Password field to the same entry?

Yes. There is an id and label for each item. id is a unique value. label is what is visible in the UI. The plugins favor label over id when looking for the requested value. The first matched value is returned.

[felixfontein]

Sounds like a good matching algorithm needs to be somewhat complex then :)

[rembart]

@felixfontein for clarification: the problem is that the behaviour of the lookup plugin changed from case-insensitive to case-sensitive causing quite a lot of fallout, since 1password used to display all section names, always, in upper case letters, for several years and still does it on the mac client in the default views (on edit you get, since a year or so, the correct upper/lower strings) so we got a lot of those upper-case lookups in our ansible code that are now failing

[samdoran]

I see the issue now. When I wrote the v2 code, I did not make it case insensitive like the v1 code is. This is a regression.

[felixfontein]

Ah, that's good to know! Thanks for the update!

[samdoran]

@rembart @bitjip Could you test with #7564 to see if that resolves this issue?