[SPIP Zone] Notice PHP - formidable v3.27.0 - PHP7.1

Archives Zone
1

Bonsoir,

Depuis la mise à jour des plugins, la notice suivante s'affiche :

PHP Notice: Undefined index: PHP_AUTH_USER in
/home/domain.tld/public_html/plugins/auto/formidable/v3.27.0/inc/formid
able.php(169) : eval()'d code on line 1\n'

Cordialement,

Eric

2

Le 14/12/2018 à 21:12, eric a écrit :

Bonsoir,

Depuis la mise à jour des plugins, la notice suivante s'affiche :

PHP Notice: Undefined index: PHP_AUTH_USER in
/home/domain.tld/public_html/plugins/auto/formidable/v3.27.0/inc/formid
able.php(169) : eval()'d code on line 1\n'

Cordialement,

Eric
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

à quel moment ? peux tu me guider pour reproduire cela ?

3

> Bonjour,

à quel moment ? peux tu me guider pour reproduire cela ?

Je vais essayer de pister les pages qui provoque cela.

Eric

4

à quel moment ? peux tu me guider pour reproduire cela ?

Cela survient lors du chargement d'une page contenant un formulaire.
Je t'envoie un export yaml de celui-ci sur ton mail perso ?

5

à quel moment ? peux tu me guider pour reproduire cela ?

Pour reproduire :

- configurer les traitements
- cocher "Résultats anonymes (ne pas garder de traces de l’identifiant
des personnes ayant répondu).

- Quelle variable système utiliser pour calculer une valeur unique pour
chaque auteur sans pour autant révéler son identité.

Si aucun choix de fait : laisser "choisir une variable parmi celles
proposées" : pas de notice

Si variable serveur : REMOTE USER ou PHP AUTH USER sont sélectionnés :
notice :

-- AH01071: Got error 'PHP message: PHP Notice: Undefined index:
REMOTE_USER in
/home/opalesurfcasting/public_html/plugins/auto/formidable/v3.27.0/inc/
formidable.php(169) : eval()'d code on line 1\n'

ou

-- AH01071: Got error 'PHP message: PHP Notice: Undefined index:
PHP_AUTH_USER in
/home/domain.tld/public_html/plugins/auto/formidable/v3.27.0/inc/formid
able.php(169) : eval()'d code on line 1\n'

Historique :

Formidable 3.12.1 - juin 2018)

PHP7.0 à PHP7.1 il y a 2 mois

Formidable 3.27.0 il y a quelques jours.

Les formulaires n'ont pas été modifiés depuis décembre/janvier 2018.

La notice est apparue avec la mise à jour du plugin.

Si une page contenant un formulaire avec anonymisation + variable
serveur PHP est affichée : notice.

6

Le 16/12/2018 à 01:52, eric a écrit :

à quel moment ? peux tu me guider pour reproduire cela ?

Cela survient lors du chargement d'une page contenant un formulaire.
Je t'envoie un export yaml de celui-ci sur ton mail perso ?
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

oui, envoi moi un export yaml, ce sera plus simple

7

Le 16/12/2018 à 02:43, eric a écrit :

à quel moment ? peux tu me guider pour reproduire cela ?

Pour reproduire :

- configurer les traitements
- cocher "Résultats anonymes (ne pas garder de traces de l’identifiant
des personnes ayant répondu).

- Quelle variable système utiliser pour calculer une valeur unique pour
chaque auteur sans pour autant révéler son identité.

Si aucun choix de fait : laisser "choisir une variable parmi celles
proposées" : pas de notice

Si variable serveur : REMOTE USER ou PHP AUTH USER sont sélectionnés :
notice :

-- AH01071: Got error 'PHP message: PHP Notice: Undefined index:
REMOTE_USER in
/home/opalesurfcasting/public_html/plugins/auto/formidable/v3.27.0/inc/
formidable.php(169) : eval()'d code on line 1\n'

ou

-- AH01071: Got error 'PHP message: PHP Notice: Undefined index:
PHP_AUTH_USER in
/home/domain.tld/public_html/plugins/auto/formidable/v3.27.0/inc/formid
able.php(169) : eval()'d code on line 1\n'

Historique :

Formidable 3.12.1 - juin 2018)

PHP7.0 à PHP7.1 il y a 2 mois

Formidable 3.27.0 il y a quelques jours.

Les formulaires n'ont pas été modifiés depuis décembre/janvier 2018.

La notice est apparue avec la mise à jour du plugin.

Si une page contenant un formulaire avec anonymisation + variable
serveur PHP est affichée : notice.

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Bon, j'ai testé tes fichiers.
1. Je ne reproduisais pas l'erreur
2. Je vois pas trop ce qui a pu la produire, puisqu'il n'y pas eu de changement dans ces bouts de code depuis belle lurette
3. Cela étant, je viens de commiter quelquechose qui devrait resoudre ce problème
4. Toujours cependant, ce n'est pas normal que ton serveur affiche publiquement les erreurs, et qu'il affiche aussi toutes les notices
5. Par ailleurs, la config de formidable n'est pas clairw. En effet, ces règlages pour l'anonymisation concernent :
  1. Uniquement les gens authentifié, cela éviter d'enregistrer l'id de la personne qui s'est connecté
  2. Necessite une authentification Apache ou PHP, qui n'est pas activé par défaut dans SPIP
6. Pour les gens qui ne sont pas connecté, il y a pose de cookies pour vérifier que la réponse est unique.

Du coup, j'aurias tendance à dire que je vois pas trop l'intéret de ces règlages, et qu'en plus ils donnent l'impression d'une vrai / fausse anonymisation, ce qui n'est pas le cas.

8

Bonjour,

j'ai testé tes fichiers.
1. Je ne reproduisais pas l'erreur
2. Je vois pas trop ce qui a pu la produire, puisqu'il n'y pas eu de
changement dans ces bouts de code depuis belle lurette

3. Cela étant, je viens de commiter quelquechose qui devrait resoudre
ce problème

Merci.

4. Toujours cependant, ce n'est pas normal que ton serveur affiche
publiquement les erreurs, et qu'il affiche aussi toutes les notices

Si, j'utilse d'autres outils que SPIP, pour le même domaire. Le serveur
est donc configuré pour envoyer les notices dans les logs serveurs.
J'aime bien savoir. Rien ne s'affiche pour le visiteur.

5. Par ailleurs, la config de formidable n'est pas clair. En effet,
ces règlages pour l'anonymisation concernent :
  1. Uniquement les gens authentifié, cela éviter d'enregistrer
l'id de a personne qui s'est connecté
  2. Necessite une authentification Apache ou PHP, qui n'est pas
activé par défaut dans SPIP
6. Pour les gens qui ne sont pas connecté, il y a pose de cookies
pour vérifier que la réponse est unique.

Du coup, j'aurais tendance à dire que je vois pas trop l'intéret de
ces règlages, et qu'en plus ils donnent l'impression d'une vrai /
fausse anonymisation, ce qui n'est pas le cas.

Il faut donc ne sélectionner aucune des 2 options.

Je vais voir ce que contient le cookie.

Merci,

Eric

9

Le 17/12/2018 à 13:20, eric a écrit :

Bonjour,

3. Cela étant, je viens de commiter quelquechose qui devrait resoudre
ce problème

Merci.

Du coup cela résoud?

4. Toujours cependant, ce n'est pas normal que ton serveur affiche
publiquement les erreurs, et qu'il affiche aussi toutes les notices

Si, j'utilse d'autres outils que SPIP, pour le même domaire. Le serveur
est donc configuré pour envoyer les notices dans les logs serveurs.
J'aime bien savoir. Rien ne s'affiche pour le visiteur.

ok le message était pas clair

5. Par ailleurs, la config de formidable n'est pas clair. En effet,
ces règlages pour l'anonymisation concernent :
  1. Uniquement les gens authentifié, cela éviter d'enregistrer
l'id de a personne qui s'est connecté
  2. Necessite une authentification Apache ou PHP, qui n'est pas
activé par défaut dans SPIP
6. Pour les gens qui ne sont pas connecté, il y a pose de cookies
pour vérifier que la réponse est unique.

Du coup, j'aurais tendance à dire que je vois pas trop l'intéret de
ces règlages, et qu'en plus ils donnent l'impression d'une vrai /
fausse anonymisation, ce qui n'est pas le cas.

Il faut donc ne sélectionner aucune des 2 options.

Je vais voir ce que contient le cookie.

le cookie contient un hash et/ou un identifiant aléatoire. Donc a priori pas possible de remonter à des infos perso avec (à part "ce navigateur a posté cette réponse)

Merci,

Eric

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

10

> >
Du coup cela résoud?

Je pense que l'id de session php est utilisé pour "identifier", de
façon unique la personne qui a répondu lorsque l'anonymisation de
l'auteur SPIP est demandée et si celui ci est connecté à son compte.

C'est sans doute quelque chose qui a changé avec une mise à jour de
PHP7.1.

Je teste.

Eric

11

Pour un formulaire avec :

- anonymisation cochée
- PHP_AUTH_USER sélectionné

Avant mise à jour formidable:

Le champs utilisateur : b5c3b954 (id de session PHP)

Après mise à jour formidable :

Le champs utilisateur : xxx.xxx.xxx.xxx = IP du visiteur sur 4 bytes

Donc si aucun id de session php n'est retourné, c'est l'IP compléte qui
est enregistré =

- Plusieurs réponses possibles
- Pas anonyme du tout, y compris au sens RGPD

Je cherche pourquoi, l'id de session PHP n'est plus retourné.

Le lundi 17 décembre 2018 à 15:05 +0100, eric a écrit :

>
> >
> > >
> > >
> Du coup cela résoud?
Je pense que l'id de session php est utilisé pour "identifier", de
façon unique la personne qui a répondu lorsque l'anonymisation de
l'auteur SPIP est demandée et si celui ci est connecté à son compte.

C'est sans doute quelque chose qui a changé avec une mise à jour de
PHP7.1.

Je teste.

Eric

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zo
ne

12

Le 17/12/2018 à 15:22, eric a écrit :

Pour un formulaire avec :

- anonymisation cochée
- PHP_AUTH_USER sélectionné

Avant mise à jour formidable:

Le champs utilisateur : b5c3b954 (id de session PHP)

Après mise à jour formidable :

Le champs utilisateur : xxx.xxx.xxx.xxx = IP du visiteur sur 4 bytes

Donc si aucun id de session php n'est retourné, c'est l'IP compléte qui
est enregistré =

- Plusieurs réponses possibles
- Pas anonyme du tout, y compris au sens RGPD

Je cherche pourquoi, l'id de session PHP n'est plus retourné.

Le lundi 17 décembre 2018 à 15:05 +0100, eric a écrit :

Du coup cela résoud?

Je pense que l'id de session php est utilisé pour "identifier", de
façon unique la personne qui a répondu lorsque l'anonymisation de
l'auteur SPIP est demandée et si celui ci est connecté à son compte.

C'est sans doute quelque chose qui a changé avec une mise à jour de
PHP7.1.

Je teste.

Eric

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zo
ne

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

je pense oui. Je trouve très peu de doc PHP_AUTH_USER. Perso PHP_AUTH_USER renvoi toujours vide... Et d'ailleurs avec les formulaires que tu m'a envoyé, je n'arrivais jamais au moment où il fallait tester cela.

Mais si on savait de quelle version de formidable à quelle version tu est passé, on pourrait en dire plus.

Maïeul

13

Mais si on savait de quelle version de formidable à quelle version tu
est passé, on pourrait en dire plus.

Formidable 3.12.1 - juin 2018

Formidable 3.27.0 il y a quelques jours.

14

Le 17/12/2018 à 16:23, Maïeul a écrit :

Le 17/12/2018 à 15:22, eric a écrit :

Pour un formulaire avec :

- anonymisation cochée
- PHP_AUTH_USER sélectionné

Avant mise à jour formidable:

Le champs utilisateur : b5c3b954 (id de session PHP)

Après mise à jour formidable :

Le champs utilisateur : xxx.xxx.xxx.xxx = IP du visiteur sur 4 bytes

Donc si aucun id de session php n'est retourné, c'est l'IP compléte qui
est enregistré =

- Plusieurs réponses possibles
- Pas anonyme du tout, y compris au sens RGPD

Je cherche pourquoi, l'id de session PHP n'est plus retourné.

Le lundi 17 décembre 2018 à 15:05 +0100, eric a écrit :

Du coup cela résoud?

Je pense que l'id de session php est utilisé pour "identifier", de
façon unique la personne qui a répondu lorsque l'anonymisation de
l'auteur SPIP est demandée et si celui ci est connecté à son compte.

C'est sans doute quelque chose qui a changé avec une mise à jour de
PHP7.1.

Je teste.

Eric

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zo
ne

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

je pense oui. Je trouve très peu de doc PHP_AUTH_USER. Perso PHP_AUTH_USER renvoi toujours vide... Et d'ailleurs avec les formulaires que tu m'a envoyé, je n'arrivais jamais au moment où il fallait tester cela.

Mais si on savait de quelle version de formidable à quelle version tu est passé, on pourrait en dire plus.

Maïeul
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

ce que je ne comprend pas non plus c'est comment tu peux avoir l'ip dans le champ id_auteur. Dans le champ ip, pourquoi pas (si la case est coché), mais dans id_auteur ???
il n'y a rien qui pourrait pousser à cela dans le code de formidable

De plus je ne vois pas pourquoi tu parle de l'id de session_id. De ce que je compre de la doc PHP_AUTH_USER c'est pas l'id de session php.

Enfin dans tous les cas formidable hash l'id_auteur (ou équivalent) si aonymisation demandé.

15

Le 17/12/2018 à 16:34, eric a écrit :

Mais si on savait de quelle version de formidable à quelle version tu
est passé, on pourrait en dire plus.

Formidable 3.12.1 - juin 2018

Formidable 3.27.0 il y a quelques jours.
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

bon, meme avec 3.12.1 moi l'anonymisation me donne la même info partout.

Je t'envoie en privé un zip de la version 3.12.1 pour que tu puisse au moins tester si le changement est bien lié à formidable, et pas à tes changements coté PHP

16

1 - pour les ips enregistrées, c'est le formulaire que je testé qui
avait dans les traitements "enregistrer les ips"

- Toujours avec anonymisation

- Avant mise à jour:

12 juin, 15:54 Voir la réponse b5c3b957 3355

Y compris avec enregistrer IP activé, pas de notice.

- Après mise à jour avec IP cochée (ip enregistrée):

17 décembre, 15:13 Voir la réponse xxx.xxx.xxx.xxx
3361

- Après mise à jour avec IP décochée (utilisateur vide ):

17 décembre, 16:58 Voir la réponse 3368

Ce qui a changé, c'est utilisateur qui avant prenait une valeur ...
(b5c3b957), y compris avec enregistrer les ips activé, et,
l'anonymisation ne provoquait pas de notice.

Avec ta correction dans formidable_options.php, plus de notice.

S'il est normal qu'aucune valeur ne soit donné à utilisateur sauf si
enregistrer IP est activé, c'est clos.

Merci.

Eric

17

Le 17/12/2018 à 17:41, eric a écrit :

1 - pour les ips enregistrées, c'est le formulaire que je testé qui
avait dans les traitements "enregistrer les ips"

- Toujours avec anonymisation

- Avant mise à jour:

12 juin, 15:54 Voir la réponse b5c3b957 3355

Y compris avec enregistrer IP activé, pas de notice.

- Après mise à jour avec IP cochée (ip enregistrée):

17 décembre, 15:13 Voir la réponse xxx.xxx.xxx.xxx
3361

- Après mise à jour avec IP décochée (utilisateur vide ):

17 décembre, 16:58 Voir la réponse 3368

Ce qui a changé, c'est utilisateur qui avant prenait une valeur ...
(b5c3b957), y compris avec enregistrer les ips activé, et,
l'anonymisation ne provoquait pas de notice.

Avec ta correction dans formidable_options.php, plus de notice.

S'il est normal qu'aucune valeur ne soit donné à utilisateur sauf si
enregistrer IP est activé, c'est clos.

Merci.

Eric

AH! tu parle de l'affichage des réponses (sur ?exec=formulaires_reponses&id_formulaire=xxx). Moi je regardais ce qu'il y avait en base. Donc on parlait pas de la même chose.
En fait, ce sont les intitulés qui ne sont pas corrects.
La colonne "Utilisateur" affiche le numéro d'utilisateur ou à défaut l'IP (si jamais c'est enregistré en base). Mais en base ce sont deux choses distinctes.

Par contre l'IP est hashée régulièrement (par défaut 124 jours) pour qu'on ne puisse pas y remonter.

Donc b5c3b957 ce n'est pas un id php, mais un ip hashé (l'enregistrement à plus de 124 jours).

Bref:
  - je vais modifier le code pour préciser "Utilisateur ou IP"
  - j'ai deja modifié pour rendre plus claire le role de la fonction d'anonymisation (car ne concerne que les utilisateurs authentifiés, et necessite une config PHP/Apache spécific)

Ouf! Je commençais à devenir fou.

Pour la notice, je pense que tu as un règle PHP qui a changé, ce qui explique le changement que tu as constaté.

Maïeul

18

Le 17/12/2018 à 17:56, Maïeul a écrit :

Le 17/12/2018 à 17:41, eric a écrit :

1 - pour les ips enregistrées, c'est le formulaire que je testé qui
avait dans les traitements "enregistrer les ips"

- Toujours avec anonymisation

- Avant mise à jour:

12 juin, 15:54 Voir la réponse b5c3b957 3355

Y compris avec enregistrer IP activé, pas de notice.

- Après mise à jour avec IP cochée (ip enregistrée):

17 décembre, 15:13 Voir la réponse xxx.xxx.xxx.xxx
3361

- Après mise à jour avec IP décochée (utilisateur vide ):

17 décembre, 16:58 Voir la réponse 3368

Ce qui a changé, c'est utilisateur qui avant prenait une valeur ...
(b5c3b957), y compris avec enregistrer les ips activé, et,
l'anonymisation ne provoquait pas de notice.

Avec ta correction dans formidable_options.php, plus de notice.

S'il est normal qu'aucune valeur ne soit donné à utilisateur sauf si
enregistrer IP est activé, c'est clos.

Merci.

Eric

AH! tu parle de l'affichage des réponses (sur ?exec=formulaires_reponses&id_formulaire=xxx). Moi je regardais ce qu'il y avait en base. Donc on parlait pas de la même chose.
En fait, ce sont les intitulés qui ne sont pas corrects.
La colonne "Utilisateur" affiche le numéro d'utilisateur ou à défaut l'IP (si jamais c'est enregistré en base). Mais en base ce sont deux choses distinctes.

Par contre l'IP est hashée régulièrement (par défaut 124 jours) pour qu'on ne puisse pas y remonter.

Donc b5c3b957 ce n'est pas un id php, mais un ip hashé (l'enregistrement à plus de 124 jours).

Bref:
- je vais modifier le code pour préciser "Utilisateur ou IP"
- j'ai deja modifié pour rendre plus claire le role de la fonction d'anonymisation (car ne concerne que les utilisateurs authentifiés, et necessite une config PHP/Apache spécific)

Ouf! Je commençais à devenir fou.

Pour la notice, je pense que tu as un règle PHP qui a changé, ce qui explique le changement que tu as constaté.

Maïeul
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Pour info, je viens de commiter une grosse réécriture de code sur ces fonctions.
Essentiellement de l'optimisation de code (aussi bien pour l'ordinateur que pour l'humain, car c'était un gros pataques)

Maïeul

19

Bonjour,

Pour info, je viens de commiter une grosse réécriture de code sur
ces
fonctions.
Essentiellement de l'optimisation de code (aussi bien pour
l'ordinateur
que pour l'humain, car c'était un gros pataques)

Maïeul

C'est déjà plus clair avec les étiquettes.

Mais, je ne comprends pas le caractère obligatoire de "Variable
d'anonymisation".

Si je coche "Ne pas conserver l’identifiant de la personne connectée."
sans indiquer quoi que ce soit dans "Variable d’anonymisation
(obligatoire)"

En étant connecté à mon compte SPIP : l'id_auteur est bien une valeur
anonyme retournée par la fonction formidable_scramble.

"Ne pas conserver l'identifiant des auteurs SPIP connectés "

"Obligatoire : anonymiser en remplaçant l'id d'auteur SPIP par son id
de session PHP ?"

"Variable d'identification PHP à utiliser * :"
- non - garder le fonctionnement par défaut de SPIP
- variable serveur : REMOTE_USER
- variable serveur: PHP_AUTH_USER

* Si vous ne savez pas de quoi il s'agit et que vous n'avez rien
configuré pour utiliser les sessions PHP sur votre serveur, laisser
sur "non - garder le fonctionnement par défaut"

Maintenant je sais, mais sans tes explications ....

Merci,

Eric

PS : De plus, le passage de la souris sur la liste déroulante indique :
"Veuillez sélectionner un élément de la liste".

La première ligne étant vide, on sélectionne une des 2 valeurs. En tout
cas, c'est ce que j'ai fait. N'ayant aucun message d'erreur lors de mes
tests - avant les notices ... j'en ai conclu que j'avais choisi la
bonne valeur.

20

Le 18/12/2018 à 14:00, eric a écrit :

Bonjour,

C'est déjà plus clair avec les étiquettes.

Mais, je ne comprends pas le caractère obligatoire de "Variable
d'anonymisation".

Si je coche "Ne pas conserver l’identifiant de la personne connectée."
sans indiquer quoi que ce soit dans "Variable d’anonymisation
(obligatoire)"

En étant connecté à mon compte SPIP : l'id_auteur est bien une valeur
anonyme retournée par la fonction formidable_scramble.

"Ne pas conserver l'identifiant des auteurs SPIP connectés"

"Obligatoire : anonymiser en remplaçant l'id d'auteur SPIP par son id
de session PHP ?"

"Variable d'identification PHP à utiliser * :"
- non - garder le fonctionnement par défaut de SPIP
- variable serveur : REMOTE_USER
- variable serveur: PHP_AUTH_USER

* Si vous ne savez pas de quoi il s'agit et que vous n'avez rien
configuré pour utiliser les sessions PHP sur votre serveur, laisser
sur "non - garder le fonctionnement par défaut"

Maintenant je sais, mais sans tes explications ....

Merci,

Eric

PS : De plus, le passage de la souris sur la liste déroulante indique :
"Veuillez sélectionner un élément de la liste".

La première ligne étant vide, on sélectionne une des 2 valeurs. En tout
cas, c'est ce que j'ai fait. N'ayant aucun message d'erreur lors de mes
tests - avant les notices ... j'en ai conclu que j'avais choisi la
bonne valeur.

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Tes messages ne sont pas toujours clairs, tu passe entre ce que tu vois et ce que souhaite avoir, J'ai du relire 3 fois pour comprendre le sens...

Je signale par ailleurs que vouloir un formulaire anonyme en demande nom, prénom, adresse et telephone me paraît étrange...

Cela étant, ce n'est pas évident, car le code et l'ergonomie de cette fonctionnalité n'étaient pas non plus très claire (et j'essaie de clarifier un max, mais visiblement c'est pas encore cela).

1. Formidable permet
  a. D'interdire à une personne de répondre plusieurs fois à un même formulaire
  b. De permettre à une personne de modifier sa réponse
Il faut donc qu'il puisse savoir si l'internaute à répondu, et, si oui, quel est sa réponse. Pour cela, il y a deux méthodes possibles:
  - par cookie
  - par id_auteur
C'est réglable, mais le choix n'apparaissait pas systématiquement, mais uniquement si tu demandais à ce que la personne puisse modifier sa réponse. Donc en fait, tu avais un système qui se basait SYSTEMATIQUEMENT sur le cookie (ce qu'on peut voir en analysant le .yaml que tu m'a envoyé.
2. Maintenant, cette option de "variable d'anonymisation" a été introduire, si je comprend bien l'historique
  a. Pour permettre une interdiction de réponse mutliple/une permission de modif de réponse sans cookies, avec un système d'authentification (donc deja, niveau anonymat, moyen)
  b. Mais sans l'id_auteur de SPIP
3. Pour ce faire il s'appuie sur une des deux variables PHP au choix, mais cela suppose une config spécific. Dans le cas contraire, la variable est vide. C'était ton cas, et donc tu avais un variable d'identification qui était toujours la même. Mais comme tu t'en servais pas, cela n'avait aucune importance.

4. Conclusion. Il faut séparer à mon avis deux choses:
  - l'absence de conservation de l'id_auteur
  - la variable d'anonymisation comme mode d'identification d'une réponse

Je vais de de ce pas coder quelque pour cela.