Add support for application passwords via env vars and wp-cli.yml config#151
Add support for application passwords via env vars and wp-cli.yml config#151
Conversation
Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
Adds safer ways to provide HTTP Basic Auth credentials for remote REST requests without embedding secrets in the --http URL, supporting WordPress application passwords in CI and local configs.
Changes:
- Adds credential lookup from
wp-cli.yml(http_user/http_password) as the lowest-priority source. - Adds credential lookup from environment variables (
WP_REST_CLI_AUTH_USER/WP_REST_CLI_AUTH_PASSWORD) as a medium-priority source. - Preserves URL-embedded credentials as the highest-priority source.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| $bits = parse_url( $http ); | ||
| $auth = array(); | ||
|
|
||
| // Check wp-cli config for http_user / http_password (lowest priority). | ||
| $runner = WP_CLI::get_runner(); |
There was a problem hiding this comment.
parse_url( $http ) won’t extract user / pass unless the value includes a scheme (e.g. http://user:pass@host). If a user follows the documented-style --http=user:pass@example.com (no scheme), $bits['user'] will never be set and the URL-embedded credentials won’t be applied. Consider normalizing $http to include a default scheme (similar to auto_discover_api()) before calling parse_url() so credential parsing works consistently.
| // Environment variables override config file values (medium priority). | ||
| // An empty username is not valid for authentication, so we skip if it is empty. | ||
| // An empty password is allowed (e.g. passwordless setups), consistent with URL embedding. | ||
| $env_user = getenv( 'WP_REST_CLI_AUTH_USER' ); | ||
| $env_password = getenv( 'WP_REST_CLI_AUTH_PASSWORD' ); |
There was a problem hiding this comment.
New credential-resolution behavior (wp-cli.yml keys + env vars + precedence ordering) is untested. Since there are already PHPUnit tests for Runner, please add coverage that verifies the priority order and a couple of edge cases (e.g. URL userinfo present vs env/config, env user set without env password). One approach is to extract auth resolution into a small pure helper so it can be unit-tested without making HTTP requests.
WordPress 5.6+ application passwords could only be supplied by embedding credentials in the
--httpURL, exposing secrets in shell history and process listings.Changes
inc/Runner.php: Extends credential resolution inload_remote_commands()to support three sources with explicit priority ordering:--http=admin:pass@example.com(existing, unchanged)WP_REST_CLI_AUTH_USER/WP_REST_CLI_AUTH_PASSWORDenvironment variableshttp_user/http_passwordkeys inwp-cli.ymlUsage
Environment variables (CI/CD, avoids secrets in config):
WP_REST_CLI_AUTH_USER=admin \ WP_REST_CLI_AUTH_PASSWORD="X9yS 9YYn pbaU 5H8A kJNO DEfe" \ wp --http=https://example.com rest post create --title=wibblewp-cli.yml(persistent per-project defaults):Application passwords with spaces work cleanly with both approaches without requiring URL encoding.
Original prompt
🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.