GitHub deprecating query param authentication

[nicatnite]

It seems GitHub is deprecating the ability to use query params to auth with private repos at some time. https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters

Does composer have a plan to change the way we can authenticate to private repos when running composer install to support the new changes?

[Seldaek]

It is fixed in 1.9.3, are you using that version?

[MaggotMouth]

Hi,

We updated to 1.9.3 and still get the notification from Github.

On February 7th, 2020 at 07:54 (UTC) your personal access token (docker-build) using Composer/1.9.3 (Linux; 4.19.76+; PHP 7.2.27) was used as part of a query parameter to access an endpoint through the GitHub API:

[Seldaek]

Ok maybe there is still an issue then.. What is the URL accessed, can you share that?

[MaggotMouth]

It's a link to a private repo zipball, https://api.github.com/repositories/xxxx/zipball/xxxxx

[Seldaek]

Ok, could it be you had hardcoded links with tokens in your composer.lock file or something by any chance? Because in the source I don't see any reference anymore to the query param..

[omansour]

same issue here for information.

I use the composer/satis docker image and pull the latest image

during the build I pass this config to composer :

./vendor/bin/composer config --global github-oauth.github.com "myToken"

[MaggotMouth]

Ok, could it be you had hardcoded links with tokens in your composer.lock file or something by any chance? Because in the source I don't see any reference anymore to the query param..

It does not look like it. I looked up the repo that was referenced in the warning from the Github email, and then inspected the composer.lock file in the associated project.

It references the zipball, but does not seem to have a token associated with it, it's just a URL such as referenced here:
https://developer.github.com/v3/repos/contents/#get-archive-link

[edmundofuentes]

Hi,

We're having the same issue when trying to update from a private GitHub repo on Composer 1.9.3 on Ubuntu 18.04.

We're setting a global token as we've always done with:

composer config -g github-oauth.github.com tokentokentoken

But the installer keeps failing:

Failed to download org/repo from dist: The "https://api.github.com/repos/ORG/REPO/zipball/xxxxxxxxx" file could not be downloaded (HTTP/1.1 404 Not Found)

[RuntimeException]                                                                                                                                                 
  Failed to execute git clone --no-checkout 'https://***:***@github.com/ORG/REPO.git' '/var/www/symfony/vendor/org/repo' && cd '/var/www/symfony/vendor/org/repo' && git remote add composer 'https://***:***@github.com/ORG/REPO.git' && git fetch composer && git remote set-url origin 'https://github.com/ORG/REPO.git' && git remote set-url composer 'https:  
  //github.com/ORG/REPO.git'                                                                                                                
                                                                                                                                                                     
  Cloning into '/var/www/symfony/vendor/org/repo'...                                                                                     
  remote: Repository not found.                                                                                                                                      
  fatal:***@github.com/ORG/REPO.git/' not found   

The repository configuration in the composer.jsoin file is:

        {
            "type": "git",
            "url": "https://github.com/ORG/REPO"
        }

Update
The issue appears to be related to lock files which impact my workflow:

1. Local development machine: macOS Catalina running Composer 1.9.3
2. Run composer update on the local dev machine, generates a composer.lock file
3. Push the lockfile to the production server running Composer 1.9.3 on Ubuntu 18.04
4. Run composer install on the production server <- this step fails.

The update on Step2 appears to be working correctly on my local machine, that is, using my GitHub token it appears that I'm able to pull from the private repo (I've tried clearing Composer's cache and reinitializing the project to force it to pull from the source).

However, analyzing the lock file, it appears that a url is hardcoded for the private repo in the form of: https://api.github.com/repos/ORG/REPO/zipball/xxxxxxxxxx

Is the update process different than the install? Or maybe the update process is not writing the new GitHub urls as now required?

[nicatnite]

@Seldaek Just like the others, I am indeed on composer 1.9.3. We are actually fully containerized and using the latest composer build (1.9.3) with github oauth tokens to authenticate.

Url is in the same zipball format. https://api.github.com/repos/xxxxx/xxxxx/zipball/xxxxxx

[alcohol]

@edmundofuentes please note that using git instead of vcs or github as type marks the repository as explicitly being a native git implementation only, and will not auto-detect or have any of the features implemented by the github provider/implementation.

[pluc]

Using "github" as type still triggers the deprecation warning from GitHub.

[Seldaek]

I can not reproduce this with 1.9.3.. Can someone still seeing the warning do a -vvv run and try to see if they can spot access_token=*** in the output? If so please share the full output.

[itsdarrylnorris]

I was experiencing this issue, and updating to 1.9.3 seems to fix the problem.

[omansour]

thanks all. Reading your message I think, on my cause the problem come from my usage of the docker image composer/satis wich seems still using composer 1.9.1. I will propose a PR on satis.

[andytson-inviqa]

curiously I looked at some composer plugins we use where I work, and found https://github.com/hirak/prestissimo/blob/4c52352f4bc88bbf9063e18ee94016faadde88c5/src/BaseRequest.php#L143-L148

[Seldaek]

Ok then going to close this, looks like no problem is left in Composer itself.

[REBELinBLUE]

Ooh, we are using the same plugin, that will explain it

[edmundofuentes]

I've changed the repository type to "github" in my main composer.json (as recommended by @alcohol ), deleted my /vendor/ directory, did a composer update --prefer-source, and it's now installing correctly!

The composer.lock is being written as:

    "name": "org/repo",
    "version": "dev-master",
    "source": {
        "type": "git",
        "url": "git@github.com:ORG/REPO.git",
        "reference": "abcdefxxxxx"
    },
    "dist": {
        "type": "zip",
        "url": "https://api.github.com/repos/ORG/REPO/zipball/xxxxxxxxxxx",
        "reference": "abcdefxxxxx",
        "shasum": ""
    },
    "require": {
        "angle/common-utilities": "0.3.*",
        "php": "^7.1.3",
        "symfony/orm-pack": "*"
    },
    "type": "symfony-bundle",
    "autoload": {
        "psr-4": {
            "ORG\\PROY\\BUNDLE\\": ""
        }
    },
    "license": [
        "proprietary"
    ],
    "description": "~~repo description~~",
    "support": {
        "source": "https://github.com/ORG/REPO/tree/master",
        "issues": "https://github.com/ORG/REPO/issues"
    },
    "time": "2020-02-07T13:07:10+00:00"
},

But when I run a composer install it downloads the repo correctly from GitHub.