“Why has the Composer repo got password protection? Don’t they know this is open source?” In case it is not clear to all, here is why.

Improving the Merchant Experience

Magento CE is open source – anyone can grab the code from GitHub. The password on the Composer repository is not to stop that. Magento is committed to keeping Magento CE open source. But a goal is to provide a great experience for merchants through the new Magento Marketplace (not fully released yet, due Q1 2016). The authenticated Composer repository is the best option identified so far to achieve a seamless experience for merchants (after the initial authentication step).

First it is important to remember there are different classes of merchants: those that want to spin up a simple store, install a few extensions and a theme, and get on with it; and those who have a more serious development team internally or use an external partner. Both are important to Magento. In this blog post, “merchant” usually refers to the class of merchants that don’t really want to be technically savvy, but which are a significant part of the target market for extension developers. They want a simple and painless experience. “Developers” is used for the more sophisticated class of site developers.

Once the new marketplace is fully live, what will happen is the Composer repository will include everything you have “checked out” into your Composer repo. That is, each merchant account gets its own private repository that will include only extensions that the merchant wants present.

For free extensions (and themes), that means rather than flood a merchant’s Composer repo with everything free, merchants will search through extensions and themes via the online store experience, then “check out” those extensions (and themes) they want to have in their repository. Obviously merchants won’t have to pay for free extensions, but they will have to go through checkout in order to tell the Marketplace to put those extensions into the merchant’s Composer repository.

For paid extensions, the checkout process will of course involve paying for the extension. The Magento Marketplace provides a single place a merchant can purchase extensions made available via the marketplace. It also provides a useful way to remember which extensions you have purchased, even if you are not currently using them. (Purchasing an extension does not automatically add it to your site – it just adds it to your Composer repository. You must then take an additional action to add it to your site an configure it.)

So how to ensure you only see things you checkout and protect purchases from access by other users? We use the Composer authentication capability to do this. In order to make Composer prompt for credentials, we require authentication to access the packages.json file in the repository. Once we know the user’s identity, the repository can return a packages.json file listing only the extensions and themes that user has access to.

Right now, until the Magento Marketplace is fully available, most people will only see CE in the repository – no extensions yet. (EE may be present as well, but I am not sure if the authentication has been set up yet – if not, it will be soon.) This causes the current feeling of “authentication seems like a waste of time”. It won’t be once extensions are available through the Marketplace, and even in the short term it is used to determine if you get access to EE or not.

Oh, and patches will be made available via the Composer repository for CE, EE, and extensions, providing a single place to go to locate and install patches. Again, authentication is used to determine which patches a merchant should get access to.

For the technically curious, behind the scenes there is only one real repository. We just prevent access to free things the merchant does not want and paid things they have not yet paid for. The authentication credentials are used to work out what to grant access to.

Improving the Merchant Experience Quality

The main objective of Magento investing in building a new extension marketplace was to improve the merchant experience. This is not just with the installation and upgrade/patching process, but also with the quality of extensions available. The goal is to help merchants find quality extensions that will solve problems rather just than create new ones. To achieve this several things have been done.

All extensions loaded into the marketplace are put through code and security audits. It is only possible to reliably provide feedback on extension quality if the extension is hosted in the marketplace. Otherwise it is too hard to guarantee that the code submitted to Magento for review is the same as what a merchant downloads. Magento needs to provide the download of extensions in order to ensure that the code is identical to what has been submitted for review.

It also has a side effect of making it easier to spot plagiarized code (where one extension developer may “borrow” code from another extension without honoring the license of the copied extension) and making reviews more trustworthy (the marketplace knows who purchased an extension and so can leave a review). This is all only possible by centralizing all activity, forming a closed system where purchase and feedback are all in the one place.

Authentication

When the Composer repository first launched, it used the merchant’s Magento user id and password. But this was stored in a file on disk and people were understandably not happy with this solution. More sophisticated developers really want it safe to store the authentication information under source code control (e.g. in a GIT repository) to make it easy for team members to share. So the merchant’s Magento username/password has been replaced with a credential system, where a merchant can generate a username/password pair to use, and easily disable it later if it becomes compromised – without having to shut down their whole account. See the developer documentation on how to get these credentials.

Note that the “sync” button in the Magento admin web interface uses these same credentials, and is the normal way a merchant will enter the credentials. They would not use command Composer commands to install and update extensions (like more sophisticated developers).

Magento is also unlikely to officially endorse third party repositories, again because it is too hard to provide guarantees that downloaded extensions are secure and reliable. This is not to be nasty – it is just too hard to provide guarantees on quality and security without controlling the full lifecycle.

As an aside, we had considered having a different URL per merchant (e.g. add merchant user id to the Composer repository URL), but that did not remove the need for authentication as the set of modules used by a site is potentially confidential (even if they are all free). An obviously credentials are mandatory as soon as a paid extension is purchased. The current authentication approach feels like the best all round solution.

Conclusions

Hopefully the above explains why the approach has been taken to password protect the Composer repository. It is necessary to protect paid extensions, but it is also useful even for free extensions as it allows a merchant to have a short list of “approved” extensions for use on projects, rather than having all free extensions listed in tools like the Magento Component Manager.

The end result will be a simpler and more trustworthy environment for merchants.

Note that you can still add extensions from other sources – just add additional Composer repositories to your project composer.json file and add the extensions by hand. If you do this however, be aware you can no longer use the supplied web tools to check for and install patches – currently they only work with the official Magento Composer repository. And if you do so, Magento cannot vouch for the quality or security of such extensions.

Personally, I will be discouraging anyone to set up a separate password free repository. This is not because I personally desire a password protected repository, but rather I think a separate repository has a real risk of undermining the experience of merchants, and potentially the security of their sites. And yes, I know this makes automation a bit of a pain – injecting credentials is harder. But that reminds me of an old security adage – “the opposite of security is convenience”.

Got a better approach? Feel free to comment below! I am expecting a few people to express the opinion “accounts means its not open source”. Just know in advance I understand the sentiment, but until a better solution presents itself passwords feel like the least painful solution once you take the whole picture into account. I am concerned more with improving the security profile of Magento than requiring a password to download the code base in a secure, trusted, and easily patchable way.

Disclaimer: This post expresses how I see the world and does not necessarily represent the opinions of my employer (and by so saying I can get these posts out faster!).