nginx.png

Cet article est destiné aux personnes qui rencontrent des difficultés (comme moi) à configurer correctement NGinx pour Dotclear en mode PATH_INFO.

J'ai eu quelques déboires avant de réussir à configurer NGinx pour ce site, voici les astuces de ma configuration que j'ai créée à partir d'informations estampillées sur la toile.

Si vous avez des idées d'amélioration, n'hésitez pas à laisser un commentaire. Je mettrai à jour cet article en fonction des retours reçus.

server {
        listen  80;
        server_name www.geeek.org;
 
        # Si vous n'exploitez pas les access_log, ils ne servent à rien et consomment des IO.
        access_log off;

        index index.php index.html;
        root /var/www/www.geeek.org/public_html/;

        # Seuls Feedburner possède les doit d'accès aux flux RSS du site. 
        if ($http_user_agent !~ FeedBurner) {
                rewrite ^/feed/rss2$ http://feeds.feedburner.com/blog-de-geeek last;
                rewrite ^/feed/atom$ http://feeds.feedburner.com/blog-de-geeek last;
        }
 
        # Vous pouvez préciser un deuxième mot de passe si vous êtes parano comme moi.
        location /admin {
                auth_basic "Restricted Access";
                auth_basic_user_file /etc/nginx/htpasswd/default;
                try_files $uri $uri/ /index.php;
        }

        # Bloque l'accès aux fichiers non publiables
        location ~ ^/(db|cache|plugins|inc) {
                deny all;
                return 404;
        }

        # Mécanisme de redirection avec le PATH_INFO
        location / {
                try_files $uri $uri/ @dotclear_path_info;
        }
 
        # Redirection de la requêtes avec les paramètres en PATH_INFO
        location @dotclear_path_info {
                rewrite ^/(.*) /index.php/$1 last;
        }


        # Si script PHP simple
        location ~ \.php$ {
                # With php5-fpm:
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }

       # Si script PHP en mode PATH_INFO
        location ~ \.php(/.*)$ {
                # With php5-fpm:
                fastcgi_split_path_info  ^(.+\.php)(/.+)$;
                fastcgi_param PATH_INFO   $fastcgi_path_info;
                fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}
1. Le , 12:16 par saymonz
c824a1997b3574399cd50b4eb980c032

J'utilise Nginx également depuis quelques mois, j'ai passé pas mal de temps à peaufiner ma configuration (pour Dotclear et WordPress) sans avoir l'occasion de confronter mes résultats à d'autres utilisateurs. Voilà l'occasion !

Il me semble que le try_files que tu utilise ici, avec un rewrite derrière, perd justement l'intérêt du try_files qui permet d'éviter un rewrite (avec regex, donc traitement supplémentaire) à chaque requête. Voici celui que j'utilise pour Dotclear :

try_files $uri /index.php$uri?$args;

Il fonctionne avec le fichier php.conf générique suivant, que j'inclut dans mes blocs server lorsque j'ai besoin de PHP :

index  index.php index.html index.htm;
location ~ ^(.+\.php)(/.*)?$ {
   fastcgi_split_path_info     ^(.+?\.php)(/.*)$;

   if (!-f $document_root$fastcgi_script_name) { return 404; }

   fastcgi_param  CONTENT_LENGTH     $content_length if_not_empty;
   fastcgi_param  CONTENT_TYPE       $content_type if_not_empty;
   fastcgi_param  DOCUMENT_ROOT      $document_root;
   fastcgi_param  DOCUMENT_URI       $document_uri;
   fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
   fastcgi_param  HTTPS              $https if_not_empty;
   fastcgi_param  PATH_INFO          $fastcgi_path_info if_not_empty;
   fastcgi_param  QUERY_STRING       $query_string if_not_empty;
   fastcgi_param  REDIRECT_STATUS    200;
   fastcgi_param  REMOTE_ADDR        $remote_addr;
   fastcgi_param  REMOTE_PORT        $remote_port;
   fastcgi_param  REQUEST_METHOD     $request_method;
   fastcgi_param  REQUEST_URI        $request_uri;
   fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
   fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
   fastcgi_param  SERVER_ADDR        $server_addr;
   fastcgi_param  SERVER_NAME        $http_host;
   fastcgi_param  SERVER_PORT        $server_port;
   fastcgi_param  SERVER_PROTOCOL    $server_protocol;
   fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

   fastcgi_index  index.php;
   fastcgi_pass   unix:/run/php-fpm/php-fpm.sock;
}

La regex permet de capturer tous les appels à un fichier PHP, avec ou sans PATH_INFO accolé.

Également, le try_files dans le location /admin est-il bien pertinent ? Ici, il signifie qu'un accès à une url /admin/blabla avec un fichier inconnu provoquera l'affichage de l'accueil du blog. Si c'est par "sécurité", le mieux est encore de mettre l'admin de Dotclear sur un sous-domaine dédié.

Pour finir, le deny all et le return 404 se répètent, le deny voudra renvoyer une 403 là où le return voudra envoyer une 404. Je n'ai pas testé, mais je pense que la première directive (le deny donc) prendra le pas sur l'autre. D'après la doc, les allow/deny servent à contrôler la provenance d'une requête (filtre par IP). Ici, on souhaite interdire l'accès à tous, le 404 me semble préférable, un 403 confirmerait à un éventuel attaquant qu'on a bien quelque chose à lui cacher à cette adresse.

En production, le plus sécurisé reste de sortir totalement ces fichiers de la racine servie par nginx. Dans mon cas, la racine publique ne contient que le fichier index.php, un symlink vers le dossier des thèmes, et les médias.

2. Le , 23:51 par zebron
18f3749c267bdaa819f73e15809aae4d

Bonjour,

J'ai réussi à faire fonctionner mon path_info grâce à ce modèle. Merci !

Quelques précisions: ce serait intéressant d'avoir le fichier fastcgi_params dont tu fais un include (c'est utile pour ceux qui s'y mettent) et de bien indiquer comment configurer le path_info (oui, ça parait évident mais ça peut être source d'ennui :-) )

Dernière chose, j'ai réussi à appliquer ce modèle à un blog dotclear qui se trouve à la racine du site (c'est mon cas donc ça me convient) mais je n'ai pas réussi pour un site qui se trouve en http://www.url.com/repertoire/index...

Si tu sais comment faire, cela peut être une piste pour encore mieux aidé ceux qui cherchent de l'aide sur nginx et dotclear.

Merci en tout cas, ça m'a bien aidé ! Et pour tous ceux qui ont des soucis de path_info avec nginx, essayez de débugguer avec strace. Perso, ça m'a été bien utile pour comprendre ce qui n'allait pas.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.