In this new post to his site Leonid Mamchenkov talks about some of his "adventure with Composer private repositories" in some of his deployment work with CakePHP 3 applications.

As good as the Packagist is, there is often a need for a repository or a package elsewhere. Whether it’s a commercial library, or sensitive corporate code, having an ability to store it outside of public eye and handle with the same ease and the same tool as the rest of the dependencies is a very welcome feature.

[...] We are setting up similar development and deployment process, but now for CakePHP-based projects. Things are much easier, since CakePHP 3 natively supports composer for the application itself and for its plugins. But we still have the need for private repositories here and there, so we follow the same setup as we did for WordPress.

Unfortunately he was getting a RuntimeException when he was trying to pull in a plugin through the same private repository workflow. Not only had he not seen the error before but the autoloader was configured as defined and other plugins were working with the same structure. As it turns out, it was the composer.json of the main application repository that was the problem. He includes the fix he made to the configuration on a sample CakePHP 3 project, showing how to switch it to a "vcs" type for more correct handling.

In an interesting thread on the /r/php subreddit on Reddit.com, a user noticed that Google is indexing Composer files that are in the document root of PHP applications. These files, like "composer.json" and "composer.lock" can provide detailed information about which packages and libraries are in use in the application (information disclosure).

The problem is that these files are placed in the web root of the application and not in a folder one level up, a recommended practice. The post links to a Google search that shows an example of current sites with the issue.

Another comment in the same post also reminds users not to have things like their ".git" files in the document root either as they can provide valuable information to would be attackers about your application's code. Things can be done to prevent direct access to these files in the web server configuration but it's far better to restructure the application to have them in a parent directory of the actual web root.

In his latest post Brandon Savage asks you, the Composer users out there, if you know exactly what's in your "composer.json" file. If you're not a Composer user already, he also introduces you to the tool and what it can do for you and your applications.

During the recent Crafting Code Tour, Paul Jones would ask people who was currently using Composer. It was a rare night that more than half an audience raised their hands, meaning that the best invention in the PHP world in the last three years is still not being widely used by everybody. I want to share a bit about how to get started with Composer, and why you should care in the first place.

He starts with the brief overview of what Composer is and how it works with the configuration file to pull in packages and make them available via autoloading. He shows how to download and install the tool and includes a simple "composer.json" file that installs the Monolog package. He also includes his own answer to the "what's in your file" question, showing a more advanced configuration requiring several packages and defining custom autoloading and executable directories.