Tips développement web
Voici quelques conseils que nous recommandons fortement aux développeurs web.
Scripts en crontab
- Un script en crontab devrait renvoyer ses erreurs sur stderr
- Un script en crontab ne doit renvoyer sur stderr qu’en cas d’erreur
- Un script en crontab ne doit pas rediriger stderr dans un
fichier (exemples à ne pas reproduire:
2> cron_err.log
ou> cron_err.log 2>&1
) - Un script en crontab ne doit rien renvoyer sur stdout
- Un script en crontab devrait être lancé avec une option
-quiet
ou-cron
, permettant de le lancer en mode interactif sans cette option et d’obtenir des informations (sur stdout) - Un script en crontab ne devrait pas faire de requête en curl/wget sur localhost … surtout si le script demande beaucoup de ressources ! L’utilisation d’un langage CLI est conseillé. [PHP] Dans le cas de PHP, il faut par exemple utiliser PHP CLI (qui a souvent des limitations moins restrictives qu’en mode web)
- Un script doit être lancé dans lancé dans la crontab de l’utilisateur, JAMAIS EN ROOT
- Si un script est lancé dans la crontab de root (pour une mauvaise raison donc), il ne doit être accessible que par root (en écriture ET lecture)
- Si un script lancé dans la crontab de root a des droits Unix 777, merci de vous pendre.
- Un script en crontab ne devrait pas être lancé à la minute 0, et surtout pas à 00h00. Ces heures sont maudites par tout sysadmin.
Pour gérer sa crontab, voir HowtoCrontab
Gestion des droits
- masque # 027 en mode FTP/SFTP VS masque 077 en mode web
- Si besoin des droits d’écriture pour le web :
$ chmod g+w
- Un fichier avec les droits 777 (ou 666) provoque la fonte de la banquise, dégage du CO2 et tue des bébés chats. (même le site Internet du diable lui-même n’a pas de fichier en 666.)
Détection des droits incorrects
- Détecter les fichiers non lisibles par Apache (lecture sur le groupe) :
$ find ./ -type f ! -perm /g=r -exec ls -l {} \;
- Détecter les répertoires non lisibles par Apache (lecture/exécution sur le groupe) :
$ find ./ -type d \( ! -perm /g=r -o ! -perm /g=x \) -exec ls -ld {} \;
- Détecter les fichiers/répertoires accessibles en écriture par Apache (écriture sur le groupe) :
$ find ./ -perm /g=w
- Détecter les fichiers/répertoires accessibles en écriture par tous :
$ find ./ -perm -007 -o -type f -perm -006
Wordpress
http://codex.wordpress.org/Changing_File_Permissions#Permission_Scheme_for_WordPress
Les droits d’écriture ne sont pas requis dans un cas général, mais voici les changements de droits souvent requis :
- Autoriser les uploads :
$ chmod -R g+w wp-content/uploads/
- Gérer des règles d’écritures via Wordpress :
$ chmod 660 .htaccess
- Pour éditer des thèmes via l’éditeur en ligne de Wordpress :
$ chmod -R g+w sur les thèmes que l'on veut éditer
- Si répertoire de cache :
$ chmod -R g+w cache/
- À voir selon les plugins installés (qui doivent documenter les changements de droits nécessaires)
Envoi d’email
Il est important de se pré-occuper d’utiliser un expéditeur valide pour les envois d’emails, sachant qu’il y a 2 expéditeurs :
- l’expéditeur d’enveloppe (appelé aussi Return-Path) : c’est cette adresse qui recevra les erreurs NPAI (N’habite Pas à l’Adresse Indiquée), etc.)
- l’expéditeur d’entête : c’est cette adresse qui sera visible par le destinataire final
Voici nos recommandations :
- Utiliser une adresse d’expéditeur d’enveloppe identique à celle d’expéditeur d’entête
- Utiliser une adresse personnalisée du type facteur@example.com avec un domaine que vous gérez bien sûr
- Avoir un démon OpenDKIM sur le serveur d’envoi configuré avec votre domaine, si vous êtes client Evolix ouvrez un ticket pour vérifier que c’est bien le cas
- Avoir un enregistrement SPF qui autorise l’envoi depuis le serveur d’envoi, et un enregistrement DMARC pour renforcer les vérifications SPF et/ou DKIM
- Traiter réactivement (automatiquement si possible) les erreurs du type NPAI (N’habite Pas à l’Adresse Indiquée) en arrêtant immédiatemment l’envoi vers les adresses concernées
Pour plus de détails, voir https://wiki.evolix.org/HowtoPostfix#d%C3%A9livrabilit%C3%A9
Comment faire pour régler les expéditeurs d’enveloppe et d’entête
Cela dépend des langages. En PHP, la fonction mail() ne
permet PAS de régler l’expéditeur d’enveloppe, on conseille d’utiliser
la bibliothèque PHPMailer. Il peut
également être possible de forcer l’expéditeur d’enveloppe dans la
configuration PHP via la directive sendmail_path forcée à
"/usr/sbin/sendmail -t -i -f facteur@example.com"
par
exemple, mais c’est moins pratique.
Manipulation de mots de passe
Depuis PHP >=5.5.0, le langage s’est doté de fonctions haut niveau
pour la manipulation de mot de passe. Ainsi, on a
password_hash()
qui va s’occuper du hachage du mot de passe
(algo, sel, difficulté) et password_verify()
pour la
vérification.
Si on souhaite générer un mot de passe en CLI, on peut utiliser
mkpasswd -m sha-512
en CLI pour générer des hashés. (Ou
tout autre outil cli similaire)
Performances
Compression GZIP
Vérification de la compression GZIP :
$ curl -# -I -H "Accept-Encoding: gzip" http://example.com/ | grep -i ^Content-Encoding
Content-Encoding: gzip
$ curl -# -H "Accept-Encoding: gzip" http://example.com/ | file -
/dev/stdin: gzip compressed data, from Unix