feat(auth.json): support for authorization with client TLS-certificates #12406
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Seldaek
reviewed
May 12, 2025
Seldaek
reviewed
May 12, 2025
82a61d2 to
eaa9d7f
Compare
eaa9d7f to
282bba0
Compare
2957295 to
c33bc04
Compare
|
@Seldaek I updated PR:
|
stof
reviewed
May 19, 2025
c33bc04 to
9de82ab
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
With this change it will be possible to specify client-side TLS-certificate per origin.
It could be used in cases when a repository requires TLS-certificate to make an HTTPS request, ex. private package registry.
Technically without this PR it's possible to use client certificates for registries (by using
repositoriessection ofcomposer.json), but in that case path to certificate/key will we stored within thecomposer.lock, but when it is stored in VCS and each developer/CI has it's own certificate it stops working, for details see #12019.Changes made by the way:
AuthHelper::addAuthenticationOptionsto allow AuthHelper configure request options not only headers (to make this pr possible) and deprecateAuthHelper::addAuthenticationHeaderAuthHelper::addAuthenticationOptions, that helps simplify unit-test a bit - just noticed that during test implementation.Examples (auth.json)
Minimal (certificate and key are in one file, the key is unencrypted):
{ "client-certificate": { "exmaple.org": { "local_cert": "/path/to/cert.key.pem" } } }Certificate and key are in separated files file, the key is unencrypted
{ "client-certificate": { "exmaple.org": { "local_cert": "/path/to/cert.pem", "local_pk": "/path/to/key.pem" } } }Certificate and key are in separated files file, the key is encrypted
{ "client-certificate": { "exmaple.org": { "local_cert": "/path/to/cert.pem", "local_pk": "/path/to/key.pem", "passphrase": "$uper$ecret" } } }Is it breaking change?
In general - no.
There may be some packages that rely on the deprecated
AuthHelper::addAuthenticationHeadermethod, usage of which will triggerE_USER_DEPRECATED.Is there other issues?
This PR doesn't bring issues by itself.
But there could be issues when
auth.jsonhas options multiple configurations for one domain (http-basic + client-cerntifcate), but the same issue will appear when there is configurationhttp-basic + bearer; in this case there will be a warning in log sayingYou should avoid overwriting already defined auth settings.Other suggestions?
array{username: string|null, password: string|null}), forces all types of authentications to use this array in very odd way, ex. usingpasswordfield as "authentication type", this PR usejson_encode/json_decodeto store configuration withinusernameand usingpasswordto keep track authentication type;http-basic + bearerorhttp-basic + client-certificate), because of the way authentications are stored (array<origin_name, mixed>);transport-optionsinauth.json(like is done in lock file), but in this case the file will be not about authentication, but "private transport configurations" (global or per-domain).