Help us continue to build and maintain our open source projects. We’re a small team of independent developers and every little bit helps.
Composer Authentication
Many paid WordPress plugins also offer Composer support. Typically, this is accomplished by adding the plugin repository to your composer.json file:
"repositories": [
{
"type":"composer",
"url":"https://example.com"
}
]
The actual plugin download is usually protected behind an authentication layer. This allows the plugin developer to restrict access to the plugin via Composer. The authentication credentials are stored in an auth.json file.
However, when using such plugins in a Trellis project, it is generally considered bad practice to implement this via deploy hooks or adding the auth.json to your version control.
Trellis supports authentication for multiple Composer repositories, via the Ansible Vault functionality, on a per environment configuration.
Supported authentication types
| Type | Description |
|---|---|
http-basic |
HTTP basic authentication (username/password) |
bearer |
HTTP Bearer token authentication |
github-oauth |
GitHub OAuth token |
gitlab-oauth |
GitLab OAuth token |
gitlab-token |
GitLab personal/deploy token |
bitbucket-oauth |
Bitbucket OAuth consumer key/secret |
HTTP Basic
If type is omitted, it defaults to http-basic for backward compatibility.
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: http-basic, hostname: example.com, username: my-username, password: my-password }
If the private repository doesn't use a password (because the username contains an API key for example), you can omit password:
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: http-basic, hostname: example.com, username: apikey }
Bearer
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: bearer, hostname: example.com, token: my-token }
GitHub OAuth
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: github-oauth, hostname: github.com, token: my-github-token }
GitLab OAuth
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: gitlab-oauth, hostname: gitlab.com, token: my-gitlab-oauth-token }
GitLab Token
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: gitlab-token, hostname: gitlab.com, token: my-gitlab-token }
Bitbucket OAuth
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: bitbucket-oauth, hostname: bitbucket.org, consumer_key: my-consumer-key, consumer_secret: my-consumer-secret }
Multiple repositories
Multiple private Composer repositories can be configured together:
# group_vars/<env>/vault.yml
vault_wordpress_sites:
example.com:
composer_authentications:
- { type: http-basic, hostname: example.com, username: my-username, password: my-password }
- { type: github-oauth, hostname: github.com, token: my-github-token }
- { type: bearer, hostname: private-registry.com, token: my-token }
Requirements
- Passwords and tokens should not be stored as plain text, as described in the Vault documentation
Last updated