Credentials
Connection settings come from environment variables, or from a .env file named with
-e/--env-file. Only Atlassian connection variables are read from that file; anything else in it
is ignored.
JIRA_URL=https://your-site.atlassian.netJIRA_USERNAME=you@example.com # CloudJIRA_API_TOKEN=... # CloudJIRA_PERSONAL_TOKEN=... # Server/Data Center, instead of the two above
CONFLUENCE_URL=https://your-site.atlassian.netCONFLUENCE_USERNAME=you@example.com # CloudCONFLUENCE_API_TOKEN=... # CloudCONFLUENCE_PERSONAL_TOKEN=... # Server/Data Center, instead of the two abovePrecedence
Section titled “Precedence”Explicit flags beat the environment, which beats the file’s contents. That ordering is what makes the two-file arrangement described in Write safety work: a read-scoped file can be the default, and a write-capable one is named explicitly for the one command that needs it.
simply atlassian jira issue search -e ~/atlassian.env --jql "project = PROJ"Cloud versus Server/Data Center
Section titled “Cloud versus Server/Data Center”Jira Cloud authenticates with your account email plus an
API token (JIRA_USERNAME and
JIRA_API_TOKEN). Server and Data Center use a personal access token on its own
(JIRA_PERSONAL_TOKEN) in place of those two. Set one style or the other, not both. Confluence
works the same way with the CONFLUENCE_* names.
Server/Data Center support is implemented but has not yet been verified against a live instance.
Certificate verification
Section titled “Certificate verification”Certificate verification is always on. For an instance behind an internal or agency certificate authority, trust that CA rather than disabling verification:
NODE_EXTRA_CA_CERTS=/path/to/ca.pem simply atlassian jira whoamiA JIRA_SSL_VERIFY=false or CONFLUENCE_SSL_VERIFY=false carried over from other Atlassian
tooling is rejected with an error rather than silently ignored, so nobody ends up believing
verification is off when it is on, or the reverse.
Checking what you’re connected as
Section titled “Checking what you’re connected as”simply atlassian jira whoamireports the account the current credentials resolve to. A 403 from a read-scoped token is
reported as an authentication error saying the credential cannot make changes, so a refused write
is distinguishable from a genuine permissions problem.