Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Will read configured http basic auth credentials from config.json file and apply them. #1862

Closed
wants to merge 5 commits into from

9 participants

@shochdoerfer

Extended the Composer init process to load configured http basic auth credentials and pass them to the IOInterface. That way the user is not asked for the credentials anymore (if they do match).

@shochdoerfer shochdoerfer Will read configured http basic auth credentials from users config.js…
…on file and pass the credentials to the configured IOInterface.
f91aaba
@shochdoerfer

Wondering if it is possible to write to the local config.json file? If so we could update the credential configuration when the user is asked for the password in interactive mode. The downside of the current approach is that the user needs to know the exact URL which Composer is requesting and that might not be clear to the "end user".

@shochdoerfer

Any feedback on this PR?

@Seldaek
Owner

I just would like a more exhaustive solution and saving stuff people enter (optionally I guess), if we add this without thinking about it then we end up having to support a partial solution forever.

@shochdoerfer

Any tips or pointers what you want to see in there? Allowing users to store their data seems to be a bigger change, does it? Happy to help you if you need me.

@Seldaek
Owner

Well I think we should have a $COMPOSER_HOME/auth.json storing all the user/pwd for each host, optionally encrypted with a master password which wouldn't hurt. Then when you type one in in interactive mode you should be prompted whether it should be saved (yes/no/never ask). Maybe at least updating this PR to store stuff in a new file (I think it's best for managing permissions and avoiding that a composer config dump shows your passwords) would be good, then it could be merged as an intermediate step.

@cs278

@Seldaek Using a separate file will also help people who store their dotfiles files in public location.

@shochdoerfer

Ok, cool. Will hack on that one.

@shochdoerfer

@Seldaek any chance to get the PR merged? Something required missing that I need to add?

@cs278

@shochdoerfer You've committed a copy of composer at bin/composer.phar

@shochdoerfer

@cs278 thx for pointing out.

@oliver-graetz

Are there any news about when some kind of storage for HTTP AUTH will be available in the standard Composer distribution? First the idea was to provide them via repository URL in config.json, now they shall be stored in auth.json, but this code is not in the master branch. I had to enter my Subersion credentials just once and then never again because Composer just uses the command line SVN client. But for our Satis repo I need to enter them multiple times every day. Not having a solution for this annoyance after several months is really depressing.

@oliver-graetz

Any news on this?

@cordoval

missing tests

@manuellemos

This feature is very useful to avoid that the users have to enter authentication credentials on every update from repositories that require it.

Is there any time frame expected to merge this PR or implement a similar feature in the master?

I have just made PHPClasses.org and JSClasses.org act as Composer repositories. Many authors require that the users that install their packages be authenticated. So this PR is helpful to encourage them to use Composer.

I am thinking of distributing a patched version of Composer while this PR or a similar feature is not implemented in the core, but I would rather not have to do it, as it may confuse users on where they should they get Composer from.

Is there anything else that I or somebody else can do to help having this PR merged sooner?

@shochdoerfer

@Seldaek Any chance to discuss what is needed to get the PR merged? Seems I am not the only interested in this and I really want to drive things forward.

@cordoval

I guess you guys found a workaround http://blog.bitexpert.de/blog/composer-bower-and-http-basic-auth/

@manuellemos if you don't want to confuse people then you should probably call it anything but composer

@Seldaek is there a good reason why this has not been given feedback besides missing tests? Notice this has been in their minds since March 2013. I am wanting to tackle the HTTP Basic Authentication documentation ticket however would be more complete/useful if this PR is merged.

@Seldaek thanks for your answer in advance

:baby:

@manuellemos

@cordoval I have no interest in distributing any composer binaries. I just did it because I did not see any expectation to have this patch commited any time soon. Once this patch or a similar feature becomes available, I will redirect the download of the patched version to the official composer version.

@manuellemos

Just FYI, I have developed a Composer plugin that can read authentication credentials from auth.json, so you do not need to wait for this PR to be merged. It uses the same configuration format as the one used by this patch.

The plugin is available here. It does NOT require you to be registered in the site to use it.

http://www.phpclasses.org/package/8429-PHP-Composer-plugin-to-install-JS-CSS-and-image-files.html

I have written an article to explain how to use the plugin here:

http://www.phpclasses.org/blog/package/8429/post/1-Using-Composer-to-Install-JavaScript-CSS-and-Images-Under-the-Web-Document-Directory.html

@cordoval

have you registered it on packagist? i think more people would like to use it. Can I do it if you haven't please? Thanks, great job, i thought about that as well but is very good you have done so. You rock man!

@cordoval

@manuellemos could someone adapt your plugin and upload it to github on a repo with MIT license? currently it shows as proprietary

@manuellemos

@cordoval Thanks. Sorry for the delay. Currently I pull this package from a private repository, not on GitHub or any public service.

I can send it to GitHub but I cannot promise to update it there. I will be releasing it updates soon according to the article I mentioned above though.

Anyway, in my opinion I think features like authentication read from configuration files and asset installation should make part Composer built-in soon or later. I don't know why this patch was not merged into Composer already.

BTW, The license is not proprietary. Maybe you are looking at the sample project composer.json file.

@shochdoerfer

@manuellemos I can port your changes into a separate plugin if you want. That way you do not need to maintain it in the long run.

@shochdoerfer

Had some spare time this morning and quickly hacked the plugin together, see here: https://packagist.org/packages/bitexpert/composer-authstore-plugin

Had to change the implementation by @manuellemos a bit because of some issues with our own satis repo. As it turned out accessing the the packages.json did not work because in our case as the file is also protected by the http basic auth credentials. After a bit of fumbling I could find a way to work around the problem. The plugin might be the better approach to "fix" the overall problem than applying my hacks from last year. So I would leave it up to @Seldaek to decide which route to take for merging the functionality into master.

@Seldaek
Owner

Hey just a quick word here to say that yes I know I suck for not having merged this yet. I just have been way too busy lately to think about this in depth and I'd like to have a clear view before adding this because once it's added it'll be hard to change it.

@shochdoerfer

@Seldaek Would love to talk with you at phpbnl14 how to proceed. I do not want to put too much pressure on you but somehow try to push things forward.

@shochdoerfer

Just a side-note: Before merging the PR we need to discuss if we want to solve this problem (custom credentials on a per project basis) in Composer core or if the requested functionality should be part of a separate plugin.

@fduch

Hi guys,

unfortunately I discover this issue only now, because some time ago i was solving the related issue on my own.

That was a problem with communicating from local packagist instance with private package providers (not github, not bitbucket), that are requiring http authorization, during package downloading.

The main case of mine was to omit credential storing in "public places" such composer configs. So i decided to make plugin that fetches credentials from .netrc files. Notably .netrc file is used by git itself during private package installation from sources (when dist is not available or when --prefer-source argument is specified) via composer. So netrc-based solution seems to be reasonable for me.

This plugin is called composer-netrc-auth-plugin and here it is on github.

@Seldaek @cordoval @shochdoerfer what do you think about such approach?

@shochdoerfer

@fduch To be honest, I do not know. On the one hand that`s an interesting idea, on the other hand we might be too limited by the format defined by .netrc - I do not know how extensible it is (or what features we might need in the future).

@Seldaek Seldaek referenced this pull request from a commit
@Seldaek Seldaek Rename basic-auth to http-basic, add docs/schema/config support, add …
…local auth file support, add storage to auth.json, add store-auths config option, refs #1862
90d1b6e
@Seldaek
Owner

OK I finally merged this (!) :) Github won't say it because I squashed the slightly wonky history with the composer.phar commit and all into one commit (1d15910)

I also added the project-local auth.json support from bitExpert/composer-authstore-plugin#1, and made it prompt the user to store the auth so even if you don't know anything about anything composer will ask for your credentials and then store them for later so it's not a PITA to use (see 90d1b6e).

For users of @shochdoerfer's plugin that would want to migrate away from it, please note that I renamed basic-auth to http-basic, and that you can now also move your github-oauth tokens in the auth.json file.

@Seldaek Seldaek closed this
@shochdoerfer

@Seldaek thx for the merge!

@maciej-sz

Phew, I got frighten that after self-update the authstore-plugin suddenly stopped working, but as it turns out it is no longer required :) Where is the "love it" button? :+1:

@chrischnweiss

Is there any complete documentation about how to use this?

Actually I placed a auth.json in my project-root next to the composer.json and add my SVN credentials, but my SVN server still ask for username and password.

My auth.json:

{
    "config": {
        "http-basic": {
            "satis.loc": {
                "username": "USERNAME",
                "password": "********"
            }
        }
    }
}
@Seldaek
Owner

@ChrischnWeiss remove the "config" wrapper object and it should work. It takes the entire file content as the config object kind of, so {"http-basic": ...} at the top level is enough.

@chrischnweiss

Change auth.json to:

{
    "http-basic": {
        "satis.loc": {
            "username": "USERNAME",
            "password": "***********"
        }
    }
}

...but unfortunately still no success.

@oliver-graetz

The "satis.loc" needs to be replaced by the respective hostname. But all that shouldn't matter: Composer asks you if you want to store the credentials and then it automatically creates the correct file contents. If it doesn't then perhaps you aren't using the current version. Use composer self-update and try again after that.

@chrischnweiss

@oliver-graetz Thanks for helping with the hostname. :)
Composer is up to date but know I understand the problem that I have with this. Was just a little brainfreeze on my end because not the satis server is protected but the svn server which is hosting my packages.

Maybe this PR at satis repository help me out? composer/satis#149

@shochdoerfer

@ChrischnWeiss so you are running a satis server which fetches the packages from SVN? In that case yes, the referred PR should help you. You could check out the feature branch referred in the PR and try it yourself.

@oliver-graetz

With Satis, I have not been asked for credentials for the SVN server for a much longer time than with Composer. Satis uses the svn binary for that and that features its own cache for credentials. Perhaps in your case you are using a cron task for the www-data user. Then you should create the directory /var/www/.subversion and allow the www-data user access to that directory. After that, su www-data and then once build your Satis repo manually and store the credentials.

And beware, as this might introduce security problems. Do not do this on a shared hosting server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 3, 2013
  1. @shochdoerfer

    Will read configured http basic auth credentials from users config.js…

    shochdoerfer authored
    …on file and pass the credentials to the configured IOInterface.
Commits on Jun 26, 2013
  1. @shochdoerfer
Commits on Jul 15, 2013
  1. @shochdoerfer
  2. @shochdoerfer
Commits on Aug 16, 2013
  1. @shochdoerfer
This page is out of date. Refresh to see the latest.
Showing with 58 additions and 5 deletions.
  1. +58 −5 src/Composer/Factory.php
View
63 src/Composer/Factory.php
@@ -34,14 +34,11 @@
class Factory
{
/**
- * @throws \RuntimeException
- * @return Config
+ * @return string
*/
- public static function createConfig()
+ protected static function getHomeDir()
{
- // determine home and cache dirs
$home = getenv('COMPOSER_HOME');
- $cacheDir = getenv('COMPOSER_CACHE_DIR');
if (!$home) {
if (defined('PHP_WINDOWS_VERSION_MAJOR')) {
if (!getenv('APPDATA')) {
@@ -55,6 +52,16 @@ public static function createConfig()
$home = rtrim(getenv('HOME'), '/') . '/.composer';
}
}
+
+ return $home;
+ }
+
+ /**
+ * @return string
+ */
+ protected static function getCacheDir($home)
+ {
+ $cacheDir = getenv('COMPOSER_CACHE_DIR');
if (!$cacheDir) {
if (defined('PHP_WINDOWS_VERSION_MAJOR')) {
if ($cacheDir = getenv('LOCALAPPDATA')) {
@@ -68,6 +75,18 @@ public static function createConfig()
}
}
+ return $cacheDir;
+ }
+
+ /**
+ * @return Config
+ */
+ public static function createConfig()
+ {
+ // determine home and cache dirs
+ $home = self::getHomeDir();
+ $cacheDir = self::getCacheDir($home);
+
// Protect directory against web access. Since HOME could be
// the www-data's user home and be web-accessible it is a
// potential security risk
@@ -124,6 +143,26 @@ public static function createConfig()
return $config;
}
+ /**
+ * @return Config
+ */
+ protected static function createAuthConfig()
+ {
+ $home = self::getHomeDir();
+
+ $config = new Config();
+ // add dirs to the config
+ $config->merge(array('config' => array('home' => $home)));
+
+ $file = new JsonFile($home.'/auth.json');
+ if ($file->exists()) {
+ $config->merge($file->read());
+ }
+ $config->setConfigSource(new JsonConfigSource($file));
+
+ return $config;
+ }
+
public static function getComposerFile()
{
return trim(getenv('COMPOSER')) ?: 'composer.json';
@@ -218,6 +257,20 @@ public function createComposer(IOInterface $io, $localConfig = null)
}
}
+ // load separate auth config
+ $authConfig = static::createAuthConfig();
+ if ($basicauth = $authConfig->get('basic-auth')) {
+ foreach ($basicauth as $domain => $credentials) {
+ if(!isset($credentials['username'])) {
+ continue;
+ }
+ if(!isset($credentials['password'])) {
+ $credentials['password'] = null;
+ }
+ $io->setAuthentication($domain, $credentials['username'], $credentials['password']);
+ }
+ }
+
$vendorDir = $config->get('vendor-dir');
$binDir = $config->get('bin-dir');
Something went wrong with that request. Please try again.