Unable to access fields explicitly defined through value via register variables

[kujenga]

Your environment

Collection Version: 2.2.0

Connect Server Version: 1.5.0

OS: macos 12.2

Ansible Version: 2.12.1

What happened?

When creating a new item via onepassword.connect.generic_item as specified in the README for this repo, I am unable to reference fields that are explicitly specified through the value: method which are replaced with the value VALUE_SPECIFIED_IN_NO_LOG_PARAMETER when creating an item.

What did you expect to happen?

I was expecting to be able to reference these values through the registered variable, in the same way that generated values are able to be accessed.

Steps to reproduce

1. Create an item as described in the README here: https://github.com/1Password/ansible-onepasswordconnect-collection#example-usage in the "Create a new Item" sub-section
2. Attempt to access the value of the Codeword field via the op_item register as follows: {{ op_item.op_item.fields.Codeword.value }}
3. Observe that the output value is VALUE_SPECIFIED_IN_NO_LOG_PARAMETER

It's worth noting that this behavior does not happen for auto-generated values, just for ones that are explicitly specified.

Notes & Logs

This appears to be because of the use of no_log=True in this line:

ansible-onepasswordconnect-collection/plugins/module_utils/specs.py

Line 149 in e126355

value=dict(type="str", no_log=True),

There are a variety of ways to work around this issue, but it seemed inconsistent and surprising that values from the task definition are inaccessible, but auto-generated values are readily accessible.

[verkaufer]

👋 Thanks for reporting this issue! It's definitely not the behavior we intended. This is caused by how Ansible interprets no_log and how we create those generated values.

As you mentioned, the no_log option is hiding the value you provide to each field.value configuration. This is in line with how Ansible describes the no_log option in the argument spec.

The surprising behavior for generated fields comes from how Connect creates those values. The play simply sends the generator config to Connect and Connect returns the generated secret. As far as I know, the no_log parameter doesn't sanitize data returned from plays, just data provided to it.

---

What kind of behavior do you expect when mixing known secrets with values you want to generate?

We designed it the way we did because:

1. We wanted to protect the secrets you were providing to Connect (i.e. not leaking them when sending to Connect)
2. We assumed the generated secret needed to be returned in plaintext so you could pass its value to some other Ansible play.

Unfortunately, It looks like there's no easy way to no_log specific fields using Ansible's built-in options. Best I could find was this SO answer.