Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment variables (ENV) for passing secrets to composer.json? #6081

Closed
C-Duv opened this Issue Jan 17, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@C-Duv
Copy link

C-Duv commented Jan 17, 2017

I wonder if it would be useful (I ran into a use case where yes, it is) to pass repositories' credentials:

In the following composer.json, :

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://${REPO_USER}:${REPO_PASSWD}@repo.example.org"
        }
    ]
}

Running the following command would make Composer replace ${REPO_USER} and ${REPO_PASSWD} with the provided credentials when contacting repo.example.org

REPO_USER=extremely REPO_PASSWD=secret composer install

This would avoid storing secrets into composer.json and would ease Continuous Integration, Dockerification, etc.

My initial thought was to make environment variables interpreted in composer.json but according to few GitHub issues I stumbled upon, this will not happens to avoid making Composer too complex.
Maybe an intermediate fix could be done for credentials (such as, supporting a special environment variable syntax for repositories' credentials)?

A workaround is to create the auth.json file (as per the documentation but it's less direct and writes passwords to disk.

@stof

This comment has been minimized.

Copy link
Contributor

stof commented Jan 17, 2017

IMO, a better solution is to integrate an environment feature in the credentials system only.

Allowing env variables anywhere in composer.json becomes a nightmare, because it means that different values of the env variables could require invalidating the composer.lock (image you use the env var for the full repository URL. A different URL may have different packages)

@C-Duv

This comment has been minimized.

Copy link
Author

C-Duv commented Jan 17, 2017

My thoughts exactly: env vars for credentials only is simpler and would not break too much things.
Note that it should support multiple credentials and repo.

Example:

composer.json:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://repo1.example.org"
        },
        {
            "type": "composer",
            "url": "https://repo2.example.org"
        },
    ]
}
SATIS_REPSAUTH="repo1.example.org:extremely:secret1\nrepo2.example.org:simple:secret2" \
    composer install

# Or:

SATIS_REPSAUTH_repo1_example_org="extremely:secret1" \
SATIS_REPSAUTH_repo2_example_org="simple:secret2" \
    composer install
@Seldaek

This comment has been minimized.

Copy link
Member

Seldaek commented Jan 22, 2017

COMPOSER_AUTH lets you store the auth.json in the env var actually.. https://getcomposer.org/doc/03-cli.md#composer-auth

@Seldaek Seldaek closed this Jan 22, 2017

@TheCelavi

This comment has been minimized.

Copy link

TheCelavi commented May 25, 2018

May I ask for revising this request again, seams that there are some more use-cases here where it can be useful, per example, from: https://getcomposer.org/doc/06-config.md

  1. optimize-autoloader -> We could have variable that denotes if instance of app is in prod or dev mode (Symfony, someone?)
  2. cache-dir (cache dirs in general) -> I like this one much! On server, we can have multiple PHP docker containers with Composer installed on it. For each container, we can mount and configure same host directory to be shared in order to benefit from same cache. However, it must be configurable path if we intend to share, per example, a docker-compose.yml file on various OSes... (Mac, Linux, Windows).

Thanks!

@Seldaek

This comment has been minimized.

Copy link
Member

Seldaek commented May 31, 2018

For 1. we already have CLI flags, I don't see what an env var gains you there really, this stuff has to be in scripts anyway.

For 2. the cache dir is configurable via COMPOSER_CACHE_DIR already.

@TheCelavi

This comment has been minimized.

Copy link

TheCelavi commented May 31, 2018

  1. I know, idea is that value is provided via .env file, because we use those for configuring if we are, among other things, in prod or dev environment. There is, of course, a CLI flag for this, but this is just a matter of convenience, a DX, if we have to write a deploy script that checks env var, and then builds a command accordingly - or library can handle env vars so we dont have to write a script.

  2. Yes, idea is to provide value with env var from .env file, so composer.json may be configurable. Fixing cache dir in composer.json means that all systems must use same cache dir, because, composer.json is part of source code repository.

@ArminVieweg

This comment has been minimized.

Copy link

ArminVieweg commented Mar 14, 2019

Actually I have the case that I've got the same packages in two totally encapsulated environments. The transfer happens manually via Git.

So it would be very nice to have environment variables available provided by a .env file, for e.g. the VCS repo paths.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.