|
| 1 | +--- |
| 2 | +sidebar_position: 3 |
| 3 | +title: CLI Usage |
| 4 | +--- |
| 5 | + |
| 6 | +import Tabs from '@theme/Tabs'; |
| 7 | +import TabItem from '@theme/TabItem'; |
| 8 | + |
| 9 | +# CLI Usage |
| 10 | + |
| 11 | +The `projectaria_login` command provides login, verify, and logout for shell scripts, CI setups, and manual terminal use. It shares credentials with Aria Studio and MPS CLI via the system keyring, with an encrypted-file fallback when the keyring is unavailable. |
| 12 | + |
| 13 | +## Synopsis |
| 14 | + |
| 15 | +```bash |
| 16 | +projectaria_login [-v | --verbose] <command> [options] |
| 17 | +projectaria_login login --username <username-or-email> |
| 18 | +projectaria_login verify |
| 19 | +projectaria_login logout |
| 20 | +``` |
| 21 | + |
| 22 | +## Login |
| 23 | + |
| 24 | +The CLI auto-detects login method based on username. No flag needed to choose MMA vs password. |
| 25 | + |
| 26 | +:::note Already logged in |
| 27 | +If a valid token already exists (in the keyring or the encrypted file), `login` short-circuits before any password/MMA prompt and prints `Already logged in as <alias>`. To explicitly check login status, use the [`verify`](#verify) subcommand instead. To force a fresh login, run `projectaria_login logout` first. |
| 28 | +::: |
| 29 | + |
| 30 | +### Password Login (tfbnw.net / wptst.com distributed accounts) |
| 31 | + |
| 32 | +For distributed accounts ending in `tfbnw.net` or `*.wptst.com`. For `tfbnw.net` accounts you may omit the domain suffix — it is appended automatically. `*.wptst.com` accounts are **not** auto-completed, so you must pass the full email (e.g. `--username myuser@sub.wptst.com`); running `login --username myuser` for a wptst account would resolve to `myuser@tfbnw.net` and fail. |
| 33 | + |
| 34 | +```bash |
| 35 | +projectaria_login login --username myuser |
| 36 | +# or |
| 37 | +projectaria_login login --username myuser@tfbnw.net |
| 38 | +# wptst accounts require the full domain |
| 39 | +projectaria_login login --username myuser@sub.wptst.com |
| 40 | +``` |
| 41 | + |
| 42 | +You will be prompted securely for password (input hidden, no echo): |
| 43 | + |
| 44 | +``` |
| 45 | +Password: |
| 46 | +Successfully logged in as myuser |
| 47 | +Your login token has been saved for future use. |
| 48 | +``` |
| 49 | + |
| 50 | +If the token could not be persisted (no keyring and no usable encryption key), the login still succeeds but prints a warning instead: |
| 51 | + |
| 52 | +``` |
| 53 | +Password: |
| 54 | +Successfully logged in as myuser |
| 55 | +Warning: the token could not be saved. You will need to log in again next time. |
| 56 | +``` |
| 57 | + |
| 58 | +### MMA Login (Managed Meta Accounts) |
| 59 | + |
| 60 | +For Meta Work accounts (email like `user@company.com` or `@meta.com`). Detected automatically when `has_mma_account` returns a UID. |
| 61 | + |
| 62 | +```bash |
| 63 | +projectaria_login login --username user@meta.com |
| 64 | +``` |
| 65 | + |
| 66 | +Output: |
| 67 | + |
| 68 | +``` |
| 69 | +To log in, visit: https://work.meta.com/cli |
| 70 | +Enter the code: ABCD-EFGH |
| 71 | +
|
| 72 | +Waiting for authorization... |
| 73 | +Successfully logged in as user |
| 74 | +Your login token has been saved for future use. |
| 75 | +``` |
| 76 | + |
| 77 | +**Steps:** |
| 78 | + |
| 79 | +1. CLI prints verification URL and user code. Open URL in browser (automatically uses device flow, no password typed in terminal). |
| 80 | +2. Log in with Meta Work SSO in browser, enter code when prompted. |
| 81 | +3. CLI polls every 5 seconds until you authorize, or until the device code expires (about 5 minutes) — see the timeout note below. |
| 82 | +4. On success, token validated and saved. |
| 83 | + |
| 84 | +:::note Timeout |
| 85 | +Authorization must complete within about **5 minutes**. After that the device code expires and you must re-run `projectaria_login login` to get a new code. |
| 86 | +::: |
| 87 | + |
| 88 | +### Verbose Logging |
| 89 | + |
| 90 | +Add `-v` or `--verbose` to see debug logs: HTTP requests, keyring operations, token validation steps, and encrypted-file fallback messages. |
| 91 | + |
| 92 | +```bash |
| 93 | +projectaria_login -v login --username myuser |
| 94 | +``` |
| 95 | + |
| 96 | +Log levels: |
| 97 | + |
| 98 | +* default: WARNING and above — only errors and key actions printed |
| 99 | +* `-v`: DEBUG — full HTTP helper traces, keyring load/save attempts, GraphQL responses (tokens redacted) |
| 100 | + |
| 101 | +## Encrypted File Fallback |
| 102 | + |
| 103 | +When the system keyring is unavailable (headless servers, containers, CI/CD, minimal OS images), the token is stored in an encrypted local file at `~/.projectaria/auth_token.enc` instead. The file is encrypted with AES-256-GCM using a key derived (via PBKDF2-HMAC-SHA256) from one of: |
| 104 | + |
| 105 | +* **`PROJECTARIA_TOKEN_KEY` environment variable** — recommended for automation. When set, it is used automatically for both saving and loading, with no prompt. |
| 106 | +* **An interactive passphrase** — when the keyring is unavailable and no env var is set, the CLI prompts for an encryption passphrase at login and prompts again to decrypt the file when you run `verify` or `logout` (up to 3 attempts each). |
| 107 | + |
| 108 | +The key material must be at least **12 characters**; shorter material is rejected and the token is not saved. At login you get up to **3 attempts** to enter a valid, matching passphrase; if none succeeds, the token is left unsaved and you will need to log in again next time. |
| 109 | + |
| 110 | +```bash |
| 111 | +# Automation: no prompt, key comes from the environment |
| 112 | +export PROJECTARIA_TOKEN_KEY="a-strong-secret-passphrase" |
| 113 | +projectaria_login login --username myuser |
| 114 | +``` |
| 115 | + |
| 116 | +Example interactive login when the keyring is unavailable: |
| 117 | + |
| 118 | +``` |
| 119 | +System keyring is unavailable, so the login token will be stored in an encrypted file at /home/user/.projectaria/auth_token.enc. |
| 120 | +Tip: set the PROJECTARIA_TOKEN_KEY environment variable to avoid this prompt in automated environments. |
| 121 | +The token is encrypted with AES-256-GCM; anyone with the passphrase and file access can decrypt it. |
| 122 | +The passphrase must be at least 12 characters. |
| 123 | +
|
| 124 | +Encryption passphrase: |
| 125 | +Confirm passphrase: |
| 126 | +Successfully logged in as myuser |
| 127 | +Your login token has been saved for future use. |
| 128 | +``` |
| 129 | + |
| 130 | +In a non-interactive session with neither a `PROJECTARIA_TOKEN_KEY` nor a passphrase available, the token is not saved (a warning is logged) and you will need to log in again next time. See [Token Storage](/ark/projectaria-login/token-storage#encrypted-file-fallback) for the full security model. |
| 131 | + |
| 132 | +## Verify |
| 133 | + |
| 134 | +Check whether a valid stored token exists without logging in again: |
| 135 | + |
| 136 | +```bash |
| 137 | +projectaria_login verify |
| 138 | +``` |
| 139 | + |
| 140 | +It loads the token from the keyring or the encrypted file, validates it via `query_me`, and reports the result. If the encrypted file is passphrase-protected, it prompts for the passphrase and allows up to **3 attempts**. A wrong (but long-enough) passphrase leaves the file in place so you can retry; even after all 3 attempts fail the file is **kept**, so you can try again later with the correct passphrase. The file is removed only when it is structurally unusable (a malformed blob, an unsupported format, or a payload that decrypts but is not a valid token). |
| 141 | + |
| 142 | +``` |
| 143 | +Token is valid. Logged in as myuser |
| 144 | +``` |
| 145 | + |
| 146 | +If no valid token is found it prints `No valid token found. Please log in.` and exits with code `1`. |
| 147 | + |
| 148 | +## Logout |
| 149 | + |
| 150 | +```bash |
| 151 | +projectaria_login logout |
| 152 | +``` |
| 153 | + |
| 154 | +Performs: |
| 155 | + |
| 156 | +1. Loads the token from the keyring, or from the encrypted file (prompting for the passphrase if it is passphrase-protected) |
| 157 | +2. POST to `https://graph.oculus.com/logout` to invalidate the server-side session — best effort, continues on failure |
| 158 | +3. Deletes the keyring entry `projectaria_tools / session_auth_token` |
| 159 | +4. Deletes the encrypted file `~/.projectaria/auth_token.enc` if present |
| 160 | +5. Clears in-memory state |
| 161 | + |
| 162 | +Server-side invalidation requires a usable token, so the outcome depends on what could be loaded: |
| 163 | + |
| 164 | +| Situation | Message | Exit code | |
| 165 | +|---|---|---| |
| 166 | +| A valid token was found, invalidated server-side, and local state cleared | `Successfully logged out.` | 0 | |
| 167 | +| Local credentials cleared, but the server-side logout request failed (e.g. a network or HTTP error) | `Local credentials were cleared, but the server-side logout request failed. Your session may still be active; if so, sign out from your account settings.` | 0 | |
| 168 | +| No usable stored token — nothing stored, or a stored token that could not be loaded/decrypted (any unusable file is then removed) | `No valid stored token was available to invalidate server-side. The session may still be active, sign out from your account settings to close it.` | 0 | |
| 169 | +| A passphrase-protected file could not be decrypted (wrong passphrase, retries exhausted, or no passphrase available) — the file is kept and server-side logout is skipped | `Could not decrypt the stored token, so the encrypted file was kept and server-side logout was skipped. Retry with the correct passphrase, or delete ~/.projectaria/auth_token.enc to remove it.` | 1 | |
| 170 | + |
| 171 | +Output on the common path: |
| 172 | + |
| 173 | +``` |
| 174 | +Successfully logged out. |
| 175 | +``` |
| 176 | + |
| 177 | +After a successful logout, Aria Studio and MPS CLI will prompt for login on next use because the shared keyring entry is gone. |
| 178 | + |
| 179 | +## Exit Codes |
| 180 | + |
| 181 | +| Code | Meaning | |
| 182 | +|---|---| |
| 183 | +| 0 | Success. For `logout` this includes the cases where local credentials were cleared even if the server-side POST failed or no usable token was found. | |
| 184 | +| 1 | Any command failure: login failed or was cancelled, `verify` found no valid token, `logout` could not decrypt a passphrase-protected file (so it was kept and server-side logout was skipped), or no command specified | |
| 185 | +| 2 | Invalid or missing command-line arguments (argparse usage error) | |
| 186 | + |
| 187 | +## Examples |
| 188 | + |
| 189 | +**Check current login status** — run `verify`: it validates the stored token and reports whether you are logged in, without prompting for a fresh login. |
| 190 | + |
| 191 | +```bash |
| 192 | +projectaria_login verify |
| 193 | +# Token is valid. Logged in as myuser |
| 194 | +``` |
| 195 | + |
| 196 | +**Force re-login** by logging out first: |
| 197 | + |
| 198 | +```bash |
| 199 | +projectaria_login logout |
| 200 | +projectaria_login login --username myuser |
| 201 | +``` |
| 202 | + |
| 203 | +**Use in scripts**: the CLI always prompts for the password via `getpass` for security, so it cannot accept a non-interactive password. Set `PROJECTARIA_TOKEN_KEY` and log in once interactively, then reuse the stored token in later non-interactive runs. |
| 204 | + |
| 205 | +## Next Steps |
| 206 | + |
| 207 | +* [Token Storage](/ark/projectaria-login/token-storage) to understand keyring backends and the encrypted-file fallback |
0 commit comments