WordPress : récupérer la liste emails des membres et commentateurs photo

WordPress : récupérer les emails des utilisateurs et commentateurs

Voici plusieurs méthodes pour récupérer la liste des adresses email des utilisateurs et des commentateurs d’un site WordPress.

On peut le faire directement en SQL, avec WP-CLI, ou en exportant un fichier CSV. La meilleure méthode dépend de votre accès au serveur, du volume de données, du besoin exact, et du contexte dans lequel vous voulez utiliser ces emails.

Petite précision avant de commencer : une adresse email est une donnée personnelle. Techniquement, l’export est simple. Juridiquement, l’usage doit rester conforme au consentement donné par les personnes et à votre politique de confidentialité. Pour une newsletter ou de la prospection, on ne mélange pas “a commenté un article en 2014” avec “a demandé à recevoir mes emails marketing”. La CNIL rappelle que, pour les particuliers, la prospection par email nécessite en principe un consentement préalable, libre, spécifique, éclairé et univoque. CNIL : prospection commerciale par courrier électronique

Emails des membres WordPress

Dans WordPress, les utilisateurs enregistrés sont stockés dans la table wp_users si le préfixe de base de données est wp_. Cette table contient notamment la colonne user_email. La documentation du schéma de base WordPress liste bien wp_users comme table des utilisateurs. WordPress Codex : Database Description

La requête SQL la plus simple pour récupérer les emails des membres est :

SELECT DISTINCT user_email
FROM wp_users
WHERE user_email <> ''
ORDER BY user_email ASC;Code language: HTML, XML (xml)

La clause DISTINCT évite les doublons. Le GROUP BY n’est pas nécessaire ici, car on ne fait pas d’agrégation. DISTINCT suffit.

Si votre préfixe WordPress n’est pas wp_, adaptez le nom de table :

SELECT DISTINCT user_email
FROM monprefix_users
WHERE user_email <> ''
ORDER BY user_email ASC;Code language: HTML, XML (xml)

Lire la suite

BIND9 : supprimer le message "success resolving after reducing the advertised EDNS UDP packet size to 512 octets" des logs photo

BIND9 : corriger les logs EDNS UDP packet size 512

Voici un autre message croisé dans les logs de BIND9, généralement dans /var/log/daemon.log, /var/log/syslog ou via journalctl :

named: success resolving DOMAIN after reducing the advertised EDNS UDP packet size to 512 octets
named: success resolving DOMAIN after disabling EDNSCode language: HTTP (http)

Ce message signifie que BIND a réussi à résoudre le domaine, mais seulement après avoir réduit la taille UDP EDNS annoncée, ou après avoir désactivé EDNS pour cette requête.

Autrement dit : la résolution finit par fonctionner, mais le chemin réseau ou le serveur DNS distant ne gère pas correctement les requêtes EDNS avec une taille UDP plus grande.

À l’époque, je m’étais contenté de masquer la catégorie de logs correspondante. Aujourd’hui, je préfère commencer par comprendre le problème, puis réduire le bruit seulement si le comportement est connu et sans impact.

Comprendre EDNS et la limite historique de 512 octets

Le DNS historique sur UDP utilisait une taille de message limitée à 512 octets. EDNS, pour Extension Mechanisms for DNS, permet notamment d’annoncer une taille UDP plus grande et d’ajouter des options modernes au protocole DNS.

BIND peut donc envoyer des requêtes avec EDNS même si DNSSEC n’est pas activé. EDNS ne sert pas uniquement à DNSSEC, même si DNSSEC en dépend fortement pour transporter des réponses plus volumineuses.

Le problème apparaît lorsqu’un serveur autoritaire, un firewall, un routeur, une middlebox ou un lien réseau gère mal ces paquets UDP plus grands. BIND essaie alors une taille plus petite, parfois jusqu’à 512 octets, ou finit par désactiver EDNS pour obtenir une réponse.

L’ISC indiquait déjà que les versions supportées de BIND envoient des requêtes avec EDNS activé par défaut, et que certains équipements ou serveurs cassés peuvent provoquer ces messages de repli. Lire ISC Knowledge Base : BIND log messages about disabling EDNS.

Lire la suite

NginX : résoudre "upstream sent too big header while reading response header from upstream" photo

NginX : corriger “upstream sent too big header”

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas. Côté navigateur, j’obtenais une erreur 502 Bad Gateway. Côté logs Nginx, le message était beaucoup plus explicite :

upstream sent too big header while reading response header from upstreamCode language: JavaScript (javascript)

Ce message signifie que Nginx a bien reçu une réponse de l’upstream, par exemple PHP-FPM, mais que les en-têtes HTTP envoyés par cet upstream sont trop gros pour les buffers configurés.

En clair : le backend répond, mais Nginx n’arrive pas à lire tous les headers de réponse dans l’espace mémoire prévu. Il coupe donc court et renvoie souvent une erreur 502.

Comprendre l’erreur “upstream sent too big header”

Dans une configuration PHP classique, Nginx reçoit les réponses depuis PHP-FPM via FastCGI. La réponse contient deux parties :

  • les en-têtes HTTP, par exemple Set-Cookie, Location, Cache-Control ;
  • le corps de la réponse, c’est-à-dire le HTML, JSON, XML, etc.

L’erreur apparaît lorsque la partie “headers” dépasse la taille que Nginx peut lire avec la configuration actuelle.

La documentation Nginx indique que fastcgi_buffer_size définit la taille du buffer utilisé pour lire la première partie de la réponse FastCGI, qui contient généralement une petite réponse avec les headers. Elle indique aussi que fastcgi_buffers définit le nombre et la taille des buffers utilisés pour lire la réponse complète de l’upstream FastCGI.

Dans le cas d’un reverse proxy classique, le même problème peut exister, mais avec les directives proxy_buffer_size et proxy_buffers, pas avec fastcgi_buffer_size.

Lire la suite