Avoid storing secrets in lockfile when using package specific transport options

[KorvinSzanto]

I am working on a custom plugin that integrates an otherwise incompatible repository of PHP packages with composer.

Zip downloads from this repository require POST requests with multipart form body that includes a token and a few other parameters. Today my custom repository does the following:

$package = $this->createPackageFromRemote($remoteData);
$package->setTransportOptions([
    'http' => [
        'method' => 'POST',
        'header' => ['Content-Type: multipart/form-data; boundary=' . $boundary],
        'content' => Http::multipartBody($boundary, ['access_token' => $this->config->get('my-custom-auth')['plugins'] ?? '']),
    ],
]);

This works well other than that it stores the token in plaintext in the lockfile.

Is there an easy way for me to do this without storing secrets in the lockfile?

[KorvinSzanto]

I was able to avoid credentials in composer.lock by doing the following:

1. Stop setting package transport options in the repository
2. Set a custom type other than zip for the downloads
3. Add a custom downloader for the new custom type that sets the transport options against the package before calling Parent::download. Additionally I add a ->then callback to remove the transport options post-download, but this wasn't strictly necessary, just a precaution for the future.

I'd still like to be sure that these variables won't ever make their way to composer.lock

[stof]

If transport options were not saved in the lock file, the installation from lock would not work (as there is no related with a repository there to be able to find the transport options from another source). Using a custom download type looks like a good option for your use case.