Problème de permissions avec Magento 2

En testant Magento 2, nous sommes tombés sur une petite erreur au niveau des permissions. En effet, les fichiers statiques générés dans pub/static renvoyaient une erreur 403. Depuis Magento 2, la bonne pratique est d’utiliser les droits 770 sur les répertoires et 660 sur les fichiers. C’est une très bonne pratique, mais elle est parfois difficilement adaptable, selon les systèmes.

Dans certains cas, il est difficile d’appliquer 770 et 660 et il faut donc 755 et 644, par exemple lorsqu’on utilise PHP-FPM. Nous n’entrerons pas dans les détails ici mais globalement, si on veut utiliser 770 et 660, il faut que les répertoires et fichiers appartiennent au moins au groupe Apache ou Nginx. Et si on héberge plusieurs instances Magento appartenant à plusieurs clients sur un seul serveur, cela peut-être assez gênant. Chez Boxydev, nous avons une couche de sécurité déjà effective, avec un chroot sur mesure, donc le répertoire en 755 est déjà protégé et de plus, il appartient à un utilisateur et un groupe unique !

L’umask de Magento est prédéfini dans le framework. Il faut donc aller éditer 2 fichiers source.

vim /vendor/magento/framework/Filesystem/DriverInterface.php
vim /lib/internal/Cm/Cache/Backend/File.php

On remplace donc 770 et 660 par 755 et 644.

interface DriverInterface
{
    const WRITEABLE_DIRECTORY_MODE = 0755;
    const WRITEABLE_FILE_MODE = 0644;
}
class Cm_Cache_Backend_File extends Zend_Cache_Backend_File
{
    protected $_options = array(
        'directory_mode' => 0755,
        'file_mode' => 0644,
    );
}

On s’assure que tous les dossiers et fichiers ont les bons chmod, libre à vous de sécuriser certains fichiers sensibles avec 600 ou 660 !

find . -type d -exec chmod 755 {} \; && find . -type f -exec chmod 644 {} \;

Il est évident que modifier des vendor directement est une très mauvaise pratique ! Mais c’est la solution la plus facile que nous ayons trouvé, vu que les droits sont définis directement dans une constante. Il faut espérer que Magento corrige cela par la suite en nous laissant le choix des droits à l’installation ou en nous permettant d’override l’umask par exemple. Bien entendu, 770 et 660 sont toujours plus sécurisés que 755 et 644. Ici, on parle d’un cas où il y a déjà une sécurité alternative, comme par exemple l’isolation d’un user dans un 700 ! D’ailleurs, la gestion des droits n’a vraiment rien à faire dans l’application, c’est le système qui doit logiquement s’occuper de tout cela…

Par ailleurs, si vous avez un soucis de 404, ce sont les Symlink, en mode dev’, les ressources se chargent de cette manière mais, il faut faire une copie en dur. Pour cela, il faut éditer le fichier suivant :

vim /app/etc/di.xml
<virtualType name="developerMaterialization" type="Magento\Framework\App\View\Asset\MaterializationStrategy\Factory">
    <arguments>
        <argument name="strategiesList" xsi:type="array">
            <item name="view_preprocessed" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>
            <item name="default" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>
        </argument>
    </arguments>
</virtualType>

Boxydev passe son blog sous WordPress

Petit changement chez Boxydev. Nous avions développé un mini moteur de blog sous Symfony 2 pour Boxydev. Finalement, nous repassons par l’utilisation de WordPress. Pourquoi ?

Et bien simplement, nous ne voulons pas mélanger les torchons et les serviettes. Nous voulons aussi nous concentrer sur des fonctionnalités qui ont une plus value sur le site. Il a donc fallu décharger la fonctionnalité de blog sur une structure éprouvée qu’est WordPress. En effet, nativement, WordPress gère des articles, des catégories, des « images à la une », des fonctionnalités avancées pour poster des articles, de l’import/export. Plutôt que de perdre du temps à développer tout ça sur Symfony 2, autant utiliser WordPress et développer des choses inédites avec notre framework préféré 🙂