Skip to content

fix(plugins/bitwarden_item): point the locked-vault error at bw serve - #330

Merged
NavidSassan merged 1 commit into
mainfrom
fix/bitwarden-item-locked-vault-message
Aug 28, 2026
Merged

fix(plugins/bitwarden_item): point the locked-vault error at bw serve#330
NavidSassan merged 1 commit into
mainfrom
fix/bitwarden-item-locked-vault-message

Conversation

@markuslf

Copy link
Copy Markdown
Member

Problem

The lookup and the module read the vault through the bw serve API on 127.0.0.1:8087. That daemon keeps the session it was started with, so exporting BW_SESSION afterwards only reaches the bw CLI in the shell:

$ bw status
{"status":"unlocked", ...}

$ curl --silent http://127.0.0.1:8087/status
{"data":{"template":{"status":"locked", ...

$ tr '\0' '\n' < /proc/<pid of bw serve>/environ | grep BW_
BW_SESSION=

The old message sent the admin to bw login and bw unlock, neither of which touches a running bw serve, so the obvious next step was the wrong one.

Change

is_unlocked is replaced by status, which passes the raw value through, so the message can name what the API actually reported. The complete set of values is unauthenticated, locked and unlocked, verified against the StatusCommand of bw 2026.8.0:

private async status(userId): Promise<"unauthenticated" | "locked" | "unlocked">

Both call sites share one message builder in the module_util so they cannot drift apart. What an admin sees now:

The Bitwarden vault behind `bw serve` at http://127.0.0.1:8087 reports status "locked",
expected "unlocked". `bw serve` keeps its own session, taken from the environment it was
started in, so `bw status` in your shell can report "unlocked" while this API does not.
Run `bw login` if needed, then `export BW_SESSION="$(bw unlock --raw)"` and restart `bw serve`

The same trap is now documented in the requirements of both DOCUMENTATION blocks and in the README section that shows the bw serve setup.

Second, unrelated to the content: every raised message lost its trailing period. AnsibleError appends ". <original message>" when it wraps an exception (ansible/errors/__init__.py), so the period showed up doubled in the playbook output:

before: ... `bw unlock` first.. Not logged into Bitwarden, ...
after:  ... `bw serve`. The Bitwarden vault behind `bw serve` at ...

Tests

New TestStatus in the module_util tests covers the three status values, the message content (endpoint, status, bw serve) and the missing trailing period, with the reason in a comment. The lookup and module tests gained a settable vault status and one test each asserting that unauthenticated and locked abort without creating anything.

tox -e py313-ansible218: 135 passed. ruff, bandit and vulture clean via pre-commit.

The lookup and the module read the vault through the `bw serve` API on
127.0.0.1:8087, which keeps the session it was started with. Exporting
BW_SESSION afterwards only reaches the `bw` CLI in the shell, so
`bw status` reports "unlocked" while the API is still locked. The old
message sent the admin to `bw login` and `bw unlock`, neither of which
touches a running `bw serve`.

Replace `is_unlocked` with `status`, which passes the raw value through,
so the message can name what the API actually reported. The complete set
of values is `unauthenticated`, `locked` and `unlocked`, verified against
the StatusCommand of bw 2026.8.0. Both call sites share one message
builder in the module_util so they cannot drift apart.

Drop the trailing period from every raised message: AnsibleError appends
". <original message>" when it wraps an exception, so the period showed up
doubled in the playbook output.
@markuslf
markuslf requested a review from NavidSassan August 28, 2026 10:04
@NavidSassan
NavidSassan merged commit 91fbe12 into main Aug 28, 2026
12 checks passed
@NavidSassan
NavidSassan deleted the fix/bitwarden-item-locked-vault-message branch August 28, 2026 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants