Read whether Google 2FA is enabled, without changing it.

Availability#

This capability is implemented in source. Deployment and real Google-account, authenticated API and graphical qualification remain pending. Publishing this reference does not establish that the installed CLI or public application already provides the new interfaces.

A compatible release must expose account-security in the CLI, google_mfa_status through the managed executor and /api/account-security in Weles Web. An unknown-command refusal or HTTP 404 means that the requested interface is unavailable, not that the account has 2FA disabled. Do not fabricate release identity or bypass release admission to run an unqualified source tree.

Commands and execution#

weles account-security --provider google --login-role <skarbiec-role> starts google_mfa_status through the managed executor's POST /run with detached: true and returns the persisted run identifier; the worker selects the Skarbiec login tagged stado:role:<role> and refuses a role no item, or more than one item, plays. The provider is named and none is assumed; google is the one Weles reads, and a start without it exits 2 with account-security needs --provider naming the identity provider whose account it reads; Weles reads google. Admission is not a 2FA verdict. weles account-security --run <run-id> reads GET /diagnostics/<run-id>/file?path=run-result.json. Neither command starts a browser on the caller's machine. Both print the answer as key: value lines, or as one JSON document with --json.

Configure WELES_WORKER_API_BASE and WELES_WORKER_TOKEN for the private operator executor on the Stado-selected host. Without an explicit endpoint, the CLI and Desktop use Stado's weles-admission service route and read its bearer as the token of the item playing the worker's API role (stado credentials get --role echo-weles-api --field token); no item name is built in. HTTPS is required except for managed loopback. These settings are separate from the organization-scoped import API's WELES_API_BASE, WELES_TOKEN and WISENT_ORGANIZATION_ID. The operator token is not a human sign-in token. The executor and client must both carry the account-security request binding.

Admission preserves the requested login_role alongside the resolved login_item. Execution uses that resolved item, without selecting the role again. The admission reply and persisted run result carry the same binding so a later role reassignment cannot silently change the account being checked.

This check does not insert an account_action_logs row or depend on a database poller. Web queue submission routes refuse account-security checks and direct callers to the maintained interface.

The worker binds the requested role to one exact Skarbiec login or identity item. It reads that item's account identity, follows context.identity when present, and reuses the existing Google account browser profile on the managed host. It opens the account security overview, reads rendered text and visible accessible labels, and performs one structured observation through Brama. It submits no login form, clicks no setup control, pages nobody, and writes no account setting or secret. Google accounts are supported; this does not inspect arbitrary SMTP providers.

weles account-security --provider google --login-role <skarbiec-role>
weles account-security --run <returned-run-id>

Result contract#

A completed observation has schema weles.account-security.v1 and two_factor_enabled: true means explicitly enabled; false means explicitly disabled; null means the state was not established. ok is true only for a confirmed boolean. A missing seed, a missing turn-on button, a general protected-account message or a successful login is not a 2FA verdict.

The result identifies the requested login_item, the active account, checked_at, source_revision and the observed URL. A confirmed boolean carries exact account_evidence and status_evidence quotes from the provider page. Account mismatch, an absent explicit setting, malformed model output or a dependency failure cannot become false. Unknown observations include reason; execution failures also name operation, error and the last observed URL.

Reading an unknown observation or failed completed run exits nonzero. An accepted running request may exit zero but has no provider observation yet. The result is historical at checked_at, not a promise that the account setting has never changed. Submit a new check for a fresh observation.

Refusals and diagnosis#

login_role_required: the CLI or Desktop received no login role. Web requests accept only params.login_role and reject missing roles, item-only input and mutation fields with HTTP 400. The worker refuses roles with no unique Skarbiec item. login_item_required identifies missing item input at the lower-level worker interface. account_identity_unavailable means the selected item did not establish an email identity. These refusals do not establish a provider setting.

authenticated_profile_unavailable: no existing per-account managed profile was found. authenticated_session_required: navigation reached a different origin instead of the signed-in account. The check does not try a fresh login or send a phone prompt.

active_account_unconfirmed: the observed active account did not match the requested identity, or its evidence was absent. mfa_state_not_explicit: the page or structured observation did not establish the current two-step verification setting.

account_security_check_failed: read operation, error and the observed URL for the actual failed dependency or page operation. Skarbiec, browser and Brama failures remain unknown. result.json, observation.txt and security.png are retained when their stages were reached. The detached run-result.json retains the request binding and outcome; its execution run_id identifies the browser's diagnostic artifacts. Network errors name the failed request and endpoint, not a disabled 2FA state.

An unrelated-run refusal includes the observed run identifier, action, state and login binding. A different-request refusal includes the requested and returned identities. These are protocol failures, not Google observations; inspect the executor release and retained run before submitting another check. A missing binding from an older executor must not be accepted by relaxing the client check.

If runtime selection fails, the error retains the selected executable path and the filesystem cause, such as ENOENT for a missing file or EACCES for denied access. When neither supported per-user Stado installation can be selected, both failed paths and causes are reported. Diagnose that runtime failure before retrying the account check; it is not evidence that Google 2FA is disabled.

If the executor cannot be reached, stado workload status weles-api-runtime --target <host> --json checks the actual listener. stado host unit-log <host> com.wisent.compute.service.weles-api --lines 100 --json reads its startup refusal, including a failed Skarbiec release lookup. An active service registry row is not proof that this dependency works. Do not restart a service or bypass a release refusal to turn an unavailable check into a verdict.

For the complete credential-release refusal on that host, run stado host exec <host> --json -- stado release active-binary skarbiec --json. The receipt retains the actual target, exit code, stdout and stderr. Passing a remote host to a local release active-binary invocation is not equivalent: that command resolves only its own host. stado release doctor skarbiec --target <host> --json identifies a conflicting stable-port owner and host resource refusals. A healthy local Skarbiec executable does not establish a usable release on the remote executor.

The action accepts exactly one of params.login_role or params.login_item. Mutation parameters and CLI enable, disable or enrol flags are refused.

Graphical surfaces#

Weles Web and Weles Desktop expose Account security. Enter the Skarbiec login role, choose Check 2FA, then Refresh result. The screen shows the requested role, resolved source item, account, run state, observation time, provider quote and any refusal. Refresh checks both the role and resolved item against admission. Before an observation exists it displays Not established, never Disabled. Desktop uses the managed executor connection, resolving its route and bearer through Stado when no explicit endpoint is configured. It does not start a browser or invoke the Weles CLI.

Weles Web uses POST /api/account-security with params.login_role and GET /api/account-security?run_id=<id>. Both require a human administrator in the organization declared by the web server's WISENT_ORGANIZATION_ID. The server's WELES_WORKER_API_BASE and WELES_WORKER_TOKEN connect it to that organization's managed executor. A different organization is refused before any executor request. The human token is checked against central Wisent identity; the private worker token stays on the server. No database queue is involved. Protocol errors preserve the operation, endpoint and observed binding instead of presenting an unrelated result.

Real qualification#

Run node tests/security/account-security.mjs --login-role <test-login-role> from the Weles checkout with a dedicated real Google login and its existing authenticated profile on the managed executor. The test requires the executor to report the source revision being qualified. It exercises unauthorized and mutation refusals, the actual CLI submission, persisted identity and completed observation readback; it never launches a local browser.

If the observation is still running, the report records awaiting_observation and exits nonzero. Resume the same request with node tests/security/account-security.mjs --admission-report <report.json>; do not submit another check. Resumption reads persisted state before checking the CLI's completed readback. Diagnostic retention runs even if that readback is refused. A passing report requires the completed provider observation, the same resolved account binding and matching CLI readback. The evidence helper retains commands, exit statuses, source identity, HTTP results and available recordings under build/real-tests/account-security. A refused build, incompatible executor or unavailable provider is not a qualification pass.

From weles-web, npm run test:account-security exercises the real human-admin API with WELES_API_BASE, WISENT_ORGANIZATION_ID, WELES_TEST_HUMAN_ADMIN_TOKEN, WELES_TEST_HUMAN_MEMBER_TOKEN, WELES_TEST_OTHER_ORGANIZATION_ID, WELES_TEST_OTHER_ORGANIZATION_TOKEN, WELES_TEST_WORKER_REVISION and WELES_TEST_2FA_CASES. The fixture variable names a private JSON array whose entries give login_role, independently known login_item and account, and expected two_factor_enabled. A null expectation also supplies reason; at least one real fixture must have a known boolean setting. The deployed web revision must match the checkout. The runner covers authorization, organization, mutation, item-only input and obsolete queue refusals, admission and persisted observation readback. It retains source, HTTP results and run identifiers under build/account-security-tests. WELES_TEST_ADMISSION_REPORT resumes fully recorded admissions without submitting new checks. Running observations exit nonzero. This API qualification does not replace the dedicated-host graphical journey.

Native source delivery#

weles-desktop declares a candidate-only darwin-arm64 producer in .wisent-release.json. It uses stado product (Stado 0.22.0 or later) to consume Stado's source archive and retain its declared revision and digest without inventing a Git checkout.

After commit and push, submit the native checkout with stado release changes submit and read it back with release changes list. A client without these commands must be updated through its supported delivery path. A queued source handoff is not a build, an installed application or a Google 2FA observation.

release/build.sh requires WISENT_SOURCE_DIR, WISENT_OUTPUT_DIR, WISENT_PLATFORM, WISENT_VERSION and WISENT_SOURCE_COMMIT from the shared builder. Signing needs an explicitly selected Skarbiec certificate item, a provisioned noninteractive keychain, or certificate and private-key PEM inputs. The producer disables installation and restart, checks the bundle version and WisentSourceRevision, and stages Weles.app with the actual build log, native reports and executable digest.

A compiler, link, signing or missing-input refusal blocks that producer. Native command reports retain the failed operation, toolchain, source graph and output; inspect those before repeating the build. A built bundle does not replace the dedicated-host graphical journey. Automatic reconciliation and Stable promotion remain disabled.

stado release changes submit --source <weles-desktop-checkout> --commit <full-sha> --task <task-id> --session <session-id> --json
stado release changes list --task <task-id> --json