auto-login

# Auto-Login Launch the app already authenticated into a store, skipping the manual login UI. Backed by a `DEBUG`-only shortcut in `ProcessConfiguration.swift` that seeds `SessionManager` credentials + store ID at launch, before `AppCoordinator` decides whether to show the login screen or the tab bar. **Scope**: this skill only launches. It does not build the app, install it, or provision a site — those are the caller's responsibility (see `/build`, `/simulator`, and JN site provisioning tools/skills). ## Prerequisites - A booted simulator (use the `/simulator` skill approach if none is booted) - The app already built **and installed** for that simulator, from a `DEBUG` configuration (the default for simulator builds). If not installed yet, build first and `xcrun simctl install <UDID> <path-to-.app>`. - Credentials for the target store: - `wporg` (default) — the wp-admin username + real password (e.g. a fresh Jurassic Ninja site's admin credentials). Works with no extra setup: the app's networking layer automatically does the cookie/nonce handshake and generates+stores a proper application password on the first REST call. - `applicationPassword` — a wp-admin username + an application password created on that site (e.g. via `wp user application-password create <user> <name> --porcelain` over SSH). Use this if `wporg` doesn't work for some reason (e.g. a security plugin blocking the wp-login.php handshake). - `wpcom` — a WordPress.com username + auth token, plus the store's real numeric site ID (`store-id`). ## Usage ```bash bash .claude/skills/auto-login/Scripts/launch.sh <UDID> <site-address> <username> <secret> [auth-type] [store-id] ``` Examples: ```bash # Self-hosted / JN site via its real admin username+password (auth-type defaults to wporg) bash .claude/skills/auto-login/Scripts/launch.sh "$UDID" https://example-jn-site.com admin "real-admin-password" # Self-hosted site via an application password instead bash .claude/skills/auto-login/Scripts/launch.sh "$UDID" https://example-jn-site.com admin "abcd 1234 efgh 5678" applicationPassword # WPCom-connected site (needs the real site ID) bash .claude/skills/auto-login/Scripts/launch.sh "$UDID" https://example.com someuser somewpcomtoken wpcom 123456789 ``` The script launches twice: a seeding launch that reads the credentials and persists them to Keychain/UserDefaults, then a second plain relaunch (no debug env vars) that boots already-authenticated from the start — this is what makes launch-time steps gated on already-being-authenticated (push notification registration, analytics identity refresh) run normally, since the seeding launch alone starts out deauthenticated and misses that window. See the comments in `launch.sh` for details. After it returns, wait ~3 seconds, then verify: screenshot the simulator or use `list_ui_elements` (if mobile-mcp is available) and confirm the tab bar is visible (not the login screen), and that the store name matches the target site. ## Never commit secrets Credentials only ever exist as arguments to this one shell invocation and the resulting `SIMCTL_CHILD_*` environment variables passed to `simctl launch` — never write them to a file in this repo, a scheme, or any other persisted location. ## Known limitations These stem from the app-side `DEBUG` shortcut itself and are accepted tradeoffs, not bugs in this script: - **Don't persist these env vars on a personal Xcode scheme.** If set that way instead of via this script, every subsequent debug launch — not just the one you intended — silently re-authenticates and re-syncs. Always prefer invoking `launch.sh` fresh (it only sets them for that one `simctl launch` call). - **`wpcom` requires a real `store-id`.** This script validates that, but if you ever set the env vars directly (bypassing this script), a missing/invalid store ID for `wpcom` credentials silently falls back to the self-hosted placeholder site ID, producing a broken/inconsistent session. - **No error is surfaced on bad credentials.** Unlike the real login UI, this shortcut doesn't validate role eligibility, WooCommerce installation, or application-password validity. Bad credentials just produce a blank/broken dashboard — check the simulator's console log (`DDLogError`) if the store doesn't load. - **`wporg` needs the wp-login.php cookie/nonce handshake to succeed on first REST call.** If a security plugin (e.g. Jetpack's account-protection module) blocks that handshake, `wporg` will silently fail the same way as any other bad credentials — fall back to `applicationPassword` in that case. - If you also pass `logout-at-launch` in the same launch, auto-login will silently re-authenticate right after it deauthenticates — the two aren't designed to be combined.