Tree: 6522923cdb

cached-config-operations

main

revert-7033-patch-1

test_dylint

0.10.0

0.11.0

0.12.0

0.13.0

0.9.0

1.0.0

1.1.0

1.10.0

1.11.0

1.12.0

1.13.0

1.13.1

1.14

1.14.1

1.14.2

1.15.0

1.15.1

1.16.0

1.16.1

1.16.2

1.16.3

1.17.0

1.18.0

1.19.0

1.2.0

1.20.0

1.21.0

1.22.0

1.22.1

1.22.2

1.23.0

1.23.1

1.24.0

1.25.0

1.25.1

1.25.2

1.26.0

1.27.0

1.28.0

1.28.1

1.29.0

1.29.1

1.29.2

1.3.0

1.30.0

1.30.1

1.30.2

1.30.3

1.30.4

1.30.5

1.31.0

1.32.0

1.32.1

1.32.2

1.32.3

1.32.4

1.32.5

1.32.6

1.32.7

1.33.0

1.33.1

1.33.2

1.34.0

1.34.1

1.34.2

1.34.3

1.35.0

1.35.1

1.35.2

1.35.3

1.35.4

1.35.5

1.35.6

1.35.7

1.35.8

1.36.0

1.4.0

1.5.0

1.6.0

1.6.1

1.7.0

1.8.0

1.9.0

1.9.1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '6522923cdb'

${ noResults }

Commit Graph

3 Commits (6522923cdb1694235f4febf84419f4e68882e18f)

Author	SHA1	Message	Date
Zaid Marji	524194bbf4	config: advertise pm-2035-passkey-unlock feature flag The bundled web vault gates its lock-screen "Unlock with passkey" affordance on the `pm-2035-passkey-unlock` feature flag in `/api/config`'s `featureStates`. Without it, `WebAuthnPrfUnlockService.isPrfUnlockAvailable` short-circuits to `false` and the button never renders even for users with a PRF-enabled passkey enrolled. Vaultwarden supports PRF passkey unlock end-to-end (the `userDecryption.webAuthnPrfOptions` blob in `/api/sync` feeds the client-side unwrap), so the flag must be advertised as enabled. Extracts `build_feature_states` from the `/api/config` handler so the feature-state assembly is unit-testable without `CONFIG` initialisation, and pins both the new flag and the existing `pm-19148-innovation-archive` companion via tests in `src/api/core/mod.rs` + a `/api/config` Playwright probe in `passkey.spec.ts`.	3 weeks ago
Zaid Marji	6f2751ee79	Align UserDecryption response shapes with upstream Bitwarden Upstream's `IdentityTokenResponse.UserDecryptionOptions` model carries a **singular** `WebAuthnPrfOption`, populated solely from `UserDecryptionOptionsBuilder.WithWebAuthnLoginCredential` after a successful passkey assertion. Upstream's `SyncResponseModel.UserDecryption` model carries the **plural** `WebAuthnPrfOptions` array, populated for every PRF-enabled credential the user owns. The Bitwarden client reads each at a different point in the flow: - Singular drives the immediate post-passkey-login vault decryption (the client combines it with the PRF secret from the assertion it just performed). - Plural drives the lock-screen "Unlock with passkey" option (read from disk state populated at sync time). Vaultwarden previously emitted only the singular on the webauthn-grant response and nothing on /sync, so the lock-screen option never appeared even when the user had a PRF-enabled credential. This commit: - Adds `webAuthnPrfOptions` (plural array) to `/sync` via a new `build_webauthn_prf_options(&[WebAuthnCredential])` helper. - Extracts the singular emission into `build_webauthn_login_prf_option` and a wrapper `build_webauthn_login_response` that applies it to the output of `authenticated_response`. The wrapper makes the call site unit-testable: a regression that removes the call site trips the dead-code lint at build time (the helper's only caller). - Pins both helpers and the response-augmentation wrapper with unit tests covering shape (field names + values) and behaviour (idempotency, no-op for non-Enabled credentials, untouched payload for unsupported credentials). - Adds a playwright integration test that pins the wire-level response shapes for password-grant /connect/token and /sync against the upstream contract. The login responses for `password` and `client_credentials` grants no longer emit any PRF field (matching upstream — the singular is only populated on webauthn grant, and the plural doesn't exist on that response model at all).	2 weeks ago
Zaid Marji	c489186e4f	Add playwright tests for passkey login `passkey.spec.ts` exercises the unauthenticated and authorization-required surface that doesn't need a virtual authenticator: - `GET /identity/accounts/webauthn/assertion-options` returns the documented shape (`Content-Type: application/json`, `options` + `userVerification` + a non-empty `token`). The token format is intentionally not pinned: Vaultwarden mints a UUID, upstream Bitwarden mints a `DataProtectorTokenable`; both are opaque from the client's view. - Five back-to-back calls return five distinct tokens AND five distinct challenges — a refactor that re-used either would let an attacker replay. - The `grant_type=webauthn` token endpoint returns a generic auth-failed message for an unknown token, a malformed deviceresponse, and a structurally-valid but unsignable assertion. The regex accepts both Vaultwarden's "Passkey authentication failed." and upstream Bitwarden's "Invalid credential." — the security contract is the byte-equality between failure branches (oracle defense), not the surface text. - Every webauthn-management endpoint (`GET /api/webauthn`, attestation / assertion options, finish, update, delete) rejects anonymous callers AND callers with a garbage Bearer with 401. - Missing-required-field requests to the webauthn grant are rejected before the handler body runs (token / deviceresponse / client_id / scope). The specific rejection text differs between projects so we only assert that the response is an error. - The web vault renders the "Log in with passkey" entry point. Security-gate coverage covers forged user-handle attempts against disabled and unverified accounts plus the SSO_ONLY webauthn grant gate. The forged-handle cases create real target users but submit intentionally unsignable assertions, asserting the response stays byte-equal to the unknown-user baseline before WebAuthn verification succeeds. Adds the docker-compose environment passthrough needed for per-describe vault restarts with SIGNUPS_VERIFY and SSO_ONLY test configs. README: document the Playwright image's bake-in behavior — the Dockerfile copies `tests/` in at build time, so local edits to `*.spec.ts` are not picked up by `docker compose run Playwright` until the image is rebuilt. Verified empirically: an in-place rename of a `test('…')` title is invisible to `run` until `build Playwright` is invoked, and absolute paths through the mounted `..:/project` volume don't override Playwright's config-derived `testDir`. Add a short note next to the existing "force a rebuild" command. The spec is Firefox-compatible and runs unmodified under the existing playwright project matrix.	3 weeks ago