Preserve protected bootstrap credentials and fresh user evidence - #210
c1-squire-dev[bot] wants to merge 17 commits into
Conversation
Reject unsupported inactive password-change combinations before provider writes. Retain account identity across partial activation and duplicate outcomes, and keep observations distinct from employee takeover. Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Connector PR Review: Preserve protected bootstrap credentials and fresh user evidenceBlocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0 Review SummaryThe new commit converts Security IssuesNone found. Correctness IssuesNone found. SuggestionsNone. |
…ssword path Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
|
Addressed the remaining summary-only README help finding in 4376cda. The --strict-account-creation line is copied from the freshly built offline CLI and matches its description/environment variable exactly. This is a one-line documentation follow-up to bc4e1a4; native generator, full Go 1.25.2 tests/build, canonical lint 2.11.4, CLI config/capabilities metadata equality and MDX validation pass. |
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Co-authored-by: c1-squire-dev[bot] <c1-squire-dev[bot]@users.noreply.github.com>
Changes
Behavior
Requested password changes must be supported by the selected provider operation. No-password, inactive creation, or suppressed activation email cannot enforce mandatory password change; incompatible requests fail with
InvalidArgumentbefore writes. This deliberately replaces previously ignored combinations with explicit errors.Creation success reports the account and its actual provider status, not sign-in readiness. The existing staged-create/activate-without-email flow stays; no
InProgressresponse or transition-based readiness state machine is added. A known post-create activation/read failure uses standardActionRequiredand preserves generated material through the SDK protected-result channel instead of reporting success or losing the credential. Unresolved duplicate lookups remain errors; deprovisioned collisions retain their existingFailedPreconditionbehavior.New random-password creation honors the SDK range of 8–64 characters instead of silently truncating longer requested passwords to eight. Upgrading does not rotate existing passwords. Supplied-password and no-password modes do not use the random-length rule.
Validation
go test -p 1 -count=1 ./...-racetests, including actual SDK encryption/decryption of successful and partial creation resultsNo SDK version change, CI change, C1 implementation, deployment, or merge. Local provider scenarios use HTTP fixtures.