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 #

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 }

Custom Headers #

For private repositories that use custom HTTP headers for authentication:

# group_vars/<env>/vault.yml

vault_wordpress_sites:
  example.com:
    composer_authentications:
      - { type: custom-headers, hostname: repo.example.org, headers: ["API-TOKEN: my-api-token"] }

Multiple headers can be specified:

# group_vars/<env>/vault.yml

vault_wordpress_sites:
  example.com:
    composer_authentications:
      - { type: custom-headers, hostname: repo.example.org, headers: ["API-TOKEN: my-api-token", "X-CUSTOM-HEADER: value"] }

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