About & safety

Getting and revoking a credential

One way in: the SFDX auth URL from the Salesforce CLI. It carries the client id, the refresh token and the org's host in a single line, so nothing expires in hours and nothing has to be created in Setup first. It is stored in this browser and nowhere else.

What the SFDX auth URL is

sf org auth show-sfdx-auth-url --target-org <alias> --json

It prints one line — force://…, or the same value as result.sfdxAuthUrl in the JSON — holding the client id, the refresh token and the org's host. Paste it whole; either shape is accepted. --json is there so the CLI does not stop to ask for confirmation.

For a CLI login the client id is PlatformCLI with an empty secret, so no connected app has to be created first, and the credential keeps working until it is revoked.

How to revoke it

sf org logout --target-org <alias>

Deleting an org here only forgets it in this browser. That command, or Setup → Connected Apps OAuth Usage for your own app, is what actually invalidates it.

What that means

  • It is stored in this browser only, with the org record, in plaintext — the same place and the same way a saved session would be.
  • It is sent with every request so the API can exchange it for an access token in memory. Nothing is written server-side, and it is never logged or echoed.
  • It is longer-lived than a session id: it does not expire on its own and can mint new sessions until revoked. Treat it as a password for that sandbox.
  • The sandbox-only rule still applies — production orgs are refused whichever credential you use.
What is stored where

In this browser only: org records and their credentials — the SFDX auth URL: a refresh token with its client id and secret — plus the component index, your templates and their selections, and the folder/object/user lists. It all lives in IndexedDB, and “Forget” on an org removes it.

On the server: nothing. The backend is a stateless proxy — it decrypts your request, calls Salesforce, returns the answer and forgets it. No database, no cache, no logs of org data. If the request carried a refresh token, the API exchanges it for an access token in memory, uses it for that one request, and drops both.

On the wire: every request body is encrypted with a key that is generated per request and wrapped with the server's public key, so a captured request or an inspecting proxy sees ciphertext.

What that does not protect: anything running inside this browser. The auth URL — its refresh token, client id and secret — is plaintext in IndexedDB, so a malicious extension or an XSS on this page could read it. Treat it as a password for that sandbox, because it keeps minting sessions until it is revoked.

Clearing: wiping site data removes everything this app knows, templates included. Do that on a shared machine.

What a manifest can and cannot contain

Components owned by an installed managed package (manageableState: installed) can be listed but not retrieved into your project — Salesforce owns them. They are hidden by default; the toggle only shows you what is there.

Standard fields are not offered either, for the same reason: a manifest can only pull metadata your org owns.

Folder-based types (email templates, reports, dashboards) need the folder: members are folder-qualified, e.g. unfiled$public/Welcome.