`_SPAM_ENCRYPT_NAME` et JS se basant sur des name #1

Open
opened 2 years ago by maieul · 12 comments
maieul commented 2 years ago
Collaborator

Certains scripts JS inclus directement dans le squelette d'un formulaire se basent sur les names.

_SPAM_ENCRYPT_NAME vient casser cela. Bien sur on pourrait contourner en retrouvant les names à partir d'autres paramètres, comme les id, mais

  1. C'est tordu en terme de logique (notamemnt lorsqu'on veut pouvoir utiliser la fonction jquery https://api.jquery.com/serializearray/)
  2. Cela fait un recodage du JS parfois tarabiscoté juste pour le cas de _SPAM_ENCRYPT_NAME.

Ma proposition : un pipeline appelé à la fin de nospam_encrypt_form_name().

Les argument de ce pipleine

  • data : le fond du formulaire tel que modifié par
  • args :
    • preserve_session_name
    • jeton
    • isbot
    • equivalence : tableau d'equivalence entre les name non chiffrés et les names chiffrés

Avec cela, on pourrait modifier le JS facilement pour qu'il fonctionne tout en restant logique en terme de logique

Qu'en pense-tu @cerdic ? vois tu une manière plus intelligente de gérer cela

Certains scripts JS inclus directement dans le squelette d'un formulaire se basent sur les names. `_SPAM_ENCRYPT_NAME` vient casser cela. Bien sur on pourrait contourner en retrouvant les names à partir d'autres paramètres, comme les id, mais 1. C'est tordu en terme de logique (notamemnt lorsqu'on veut pouvoir utiliser la fonction jquery https://api.jquery.com/serializearray/) 2. Cela fait un recodage du JS parfois tarabiscoté juste pour le cas de `_SPAM_ENCRYPT_NAME`. Ma proposition : un pipeline appelé à la fin de `nospam_encrypt_form_name()`. Les argument de ce pipleine - data : le fond du formulaire tel que modifié par - args : - preserve_session_name - jeton - isbot - equivalence : tableau d'equivalence entre les name non chiffrés et les names chiffrés Avec cela, on pourrait modifier le JS facilement pour qu'il fonctionne tout en restant logique en terme de logique Qu'en pense-tu @cerdic ? vois tu une manière plus intelligente de gérer cela
Poster
Collaborator

un avis ? Je suis prêt à coder si on pense que c'est la bonne piste.

un avis ? Je suis prêt à coder si on pense que c'est la bonne piste.
Poster
Collaborator

Une petite relance sur ce point.

Une petite relance sur ce point.
Owner

Ma première impression, c'est que ça me semble commencer à être une usine à gaz d'empiler un nouveau pipeline par là-dessus.

En seconde impression, je me dis que le plus simple c'est quand même d'écrire du JS robuste qui se base par sur les name : il y a toujours moyen de faire autrement, mais bon...

En troisième impression, vu que nospam intervient sur le pipeline formulaire_fond, je me dis qu'on pourrait simplement modifier pour qu'il fasse passer dans les args la correspondance des name, a charge pour ceux qui en ont besoin d'ajouter un utilise nospam dans leur paquet.xml pour passer après dans le pipeline et du coup avoir cette liste, mais ça me parait encore bien compliqué à gérer pour écrire du JS

Et enfin je me dis que le plus simple serait d'avoir une balise #NOSPAM_ENCRYPTED_NAME{monname} utilisable dans le JS du formulaire si vraiment on a besoin des names dans le JS.

Cette balise récupérerait le _jeton et une info qui lui dit que si le form est encrypté ou non, et retournerait le name en clair ou encrypté selon les cas.

Mais si on a pas le plugin NoSpam actif, cela va produire un {monname} qui ne marchera pas.

L'astuce peut-être d'ajouter une balise, une balise #NOSPAM qui répond juste true si le plugin est actif, et du coup on peut écrire
[(#NOSPAM|?{#NOSPAM_ENCRYPTED_NAME{monname},monname})]

ce qui est un peu lourd mais marchera dans tous les cas, qu'on ait ou non le plugin nospam, que le form soit encrypté ou non.

Bref, dans tous les cas, ça serait bien d'avoir un exemple concrèt de JS de formulaire à traiter sur ce besoin, et de pas raisonner sur du vent (ce qui permettrait en sus de faire une doc et d'expliquer les différentes alternatives)

Et pour finir, c'est du code que je veux relire et valider, donc dans tous les cas si tu le code, on passe par une PR

Ma première impression, c'est que ça me semble commencer à être une usine à gaz d'empiler un nouveau pipeline par là-dessus. En seconde impression, je me dis que le plus simple c'est quand même d'écrire du JS robuste qui se base par sur les name : il y a toujours moyen de faire autrement, mais bon... En troisième impression, vu que nospam intervient sur le pipeline `formulaire_fond`, je me dis qu'on pourrait simplement modifier pour qu'il fasse passer dans les args la correspondance des name, a charge pour ceux qui en ont besoin d'ajouter un utilise nospam dans leur paquet.xml pour passer après dans le pipeline et du coup avoir cette liste, mais ça me parait encore bien compliqué à gérer pour écrire du JS Et enfin je me dis que le plus simple serait d'avoir une balise `#NOSPAM_ENCRYPTED_NAME{monname}` utilisable dans le JS du formulaire si **vraiment** on a besoin des names dans le JS. Cette balise récupérerait le `_jeton` et une info qui lui dit que si le form est encrypté ou non, et retournerait le name en clair ou encrypté selon les cas. Mais si on a pas le plugin NoSpam actif, cela va produire un `{monname}` qui ne marchera pas. L'astuce peut-être d'ajouter une balise, une balise #NOSPAM qui répond juste `true` si le plugin est actif, et du coup on peut écrire ```[(#NOSPAM|?{#NOSPAM_ENCRYPTED_NAME{monname},monname})]``` ce qui est un peu lourd mais marchera dans tous les cas, qu'on ait ou non le plugin nospam, que le form soit encrypté ou non. Bref, dans tous les cas, ça serait bien d'avoir un exemple concrèt de JS de formulaire à traiter sur ce besoin, et de pas raisonner sur du vent (ce qui permettrait en sus de faire une doc et d'expliquer les différentes alternatives) Et pour finir, c'est du code que je veux relire et valider, donc dans tous les cas si tu le code, on passe par une PR
Collaborator

je peux vous en donner un d'exemple de form encrypté : je voulais y mettre des "if" (conditions d'affichage de champs) et cela ne marchait pas, il est là en pj - l'idée est de faire afficher le champ date si le bouton radio 1 est sur un des deux "rendez-vous".
je testerai ensuite sur vos explications d'installations - merci.

je peux vous en donner un d'exemple de form encrypté : je voulais y mettre des "if" (conditions d'affichage de champs) et cela ne marchait pas, il est là en pj - l'idée est de faire afficher le champ date si le bouton radio 1 est sur un des deux "rendez-vous". je testerai ensuite sur vos explications d'installations - merci.
Poster
Collaborator

@cerdic
J'avais commencé t'écrire tout un pavé. Et puis j'ai fini par me demandé "mais comment implementer #NOSPAM_ENCRYPTED_NAME{monname} ? J'ai donc refouillé ton code. Et j'ai fait un petit essaie, en placant nospam_encode quelque part dans le code de saisie qui genere le data-afficher-si (qui est ensuite utilisé par le code JS), et cela semble marcher au premier abord.

Mais j'ai tout de même un petit doute.

C'est cette affaire de jeton : comment m'assurer qu'au sein d'un même hit j'ai tjr le même jeton utilisé lorsqu'on fait appel à nospam_encode ?

@cerdic J'avais commencé t'écrire tout un pavé. Et puis j'ai fini par me demandé "mais comment implementer `#NOSPAM_ENCRYPTED_NAME{monname}` ? J'ai donc refouillé ton code. Et j'ai fait un petit essaie, en placant `nospam_encode` quelque part dans le code de saisie qui genere le data-afficher-si (qui est ensuite utilisé par le code JS), et cela semble marcher **au premier abord**. Mais j'ai tout de même un petit doute. C'est cette affaire de jeton : comment m'assurer qu'au sein d'un même hit j'ai tjr le même jeton utilisé lorsqu'on fait appel à `nospam_encode` ?
Owner

J'ai pas fouillé mais en principe il faut décommenter cette ligne là
https://git.spip.net/spip-contrib-extensions/nospam/src/branch/master/nospam_pipelines.php#L91

pour que le _jeton soit ajouté au #ENV de chaque formulaire, et ensuite la balise doit aller le chercher dans le env via un \$Pile[0][_jeton] bien senti sur lequel elle se basera : si pas de jeton ou pas d'encryption alors elle renvoie le name d'origine, sinon elle renvoie le name encrypté

J'ai pas fouillé mais en principe il faut décommenter cette ligne là https://git.spip.net/spip-contrib-extensions/nospam/src/branch/master/nospam_pipelines.php#L91 pour que le `_jeton` soit ajouté au `#ENV` de chaque formulaire, et ensuite la balise doit aller le chercher dans le env via un `\$Pile[0][_jeton]` bien senti sur lequel elle se basera : si pas de jeton ou pas d'encryption alors elle renvoie le name d'origine, sinon elle renvoie le name encrypté
Poster
Collaborator

d'accord, je tester voir. Mais comme dit, je pense que finalement il n'y aurait peut être pas besoin de la balise, puisque je pourrais mettre le code dans le filtre php qui produit l'attribut data-afficher-si, non ? par contre faudra que je regarde ce que ca implique pour le cache, vu que chaque saisie a un cache indépendant. Bref, a fouillé. Merci en tout cas ca ouvre des pistes.

d'accord, je tester voir. Mais comme dit, je pense que finalement il n'y aurait peut être pas besoin de la balise, puisque je pourrais mettre le code dans le filtre php qui produit l'attribut data-afficher-si, non ? par contre faudra que je regarde ce que ca implique pour le cache, vu que chaque saisie a un cache indépendant. Bref, a fouillé. Merci en tout cas ca ouvre des pistes.
Owner

Attention si tu veux faire ça dans un filtre : chaque formulaire à son jeton, et il faut récupérer le jeton depuis l'environnement du formulaire pour être certain que cela fonctionne

Attention si tu veux faire ça dans un filtre : chaque formulaire à son jeton, et il faut récupérer le jeton depuis l'environnement du formulaire pour être certain que cela fonctionne
Poster
Collaborator

oui, mais alors en continuant à fouiller le code, je vois qu'ici https://git.spip.net/spip-contrib-extensions/nospam/src/branch/master/nospam_pipelines.php#L68 le troisième argument passé à la fonction nospam_encrypt_form_names(), c'est à dire $jeton, est null. Autrement dit : _SPAM_ENCRYPT_NAME n'entraine pas la prise en compte du jeton pour l'obfuscation.

Tu te rappelle pourquoi tu n'a pas passé explicitement le jeton ? (A tout prendre je préfererais que cela reste ainsi, car sinon cela veut dire multiplier encore les caches dans saisies, puisqu'on devra passer un jeton variant à chaque ip...)

oui, mais alors en continuant à fouiller le code, je vois qu'ici https://git.spip.net/spip-contrib-extensions/nospam/src/branch/master/nospam_pipelines.php#L68 le troisième argument passé à la fonction `nospam_encrypt_form_names()`, c'est à dire `$jeton`, est `null`. Autrement dit : `_SPAM_ENCRYPT_NAME` n'entraine pas la prise en compte du jeton pour l'obfuscation. Tu te rappelle pourquoi tu n'a pas passé explicitement le jeton ? (A tout prendre je préfererais que cela reste ainsi, car sinon cela veut dire multiplier encore les caches dans saisies, puisqu'on devra passer un jeton variant à chaque ip...)
Owner

Tu n'a pas lu jusqu'au bout : le fait de pas passer le jeton implique seulement que la fonction nospam_encrypt_form_names va aller le chercher dans le html du formulaire.

Et à cet endroit on ne le passe pas car on ne le connait pas : il n'est pas dans les args car je l'ai pas mis dans le contexte du formulaire pour une raison dont je ne me souviens plus

Tu n'a pas lu jusqu'au bout : le fait de pas passer le jeton implique seulement que la fonction `nospam_encrypt_form_names` va aller le chercher dans le html du formulaire. Et à cet endroit on ne le passe pas car on ne le connait pas : il n'est pas dans les args car je l'ai pas mis dans le contexte du formulaire pour une raison dont je ne me souviens plus
Poster
Collaborator

A oui. Je suis un peu perdu, car j'avais un comportement étrange que je viens de comprendre.

Je ne comprenais pas pourquoi mon test rapide semblait marchait, mais n'était pas une bonne idée.

Si dans un même hit on fait

nospam_name_encode('un_name');
//puis plus loin
nospam_name_encode('un_name','unjeton');

Et bien le resultat sera le même dans les deux cas, à cause du static $private_key dans nospam_private_key(). C'est que mon test un peu rapide l'était trop. Il s'agissait d'appeler nospam_name_encode(), sans jeton explicite, dans la fonction qui genere le data-afficher_si, laquelle est appelée AVANT nospam_encrypt_form_names. Mais évidemment avec cela on perd tout l'intérêt du chiffrement, puisque du coup on n'a plus de jeton.

=> Mon doute était fondé, même si j'arrivé pas à comprendre pourquoi
=> Il faut donc tenir systématiquent compte du jeton pour l'encryptage.

Je reprend sur les pistes pour mon problème.

Piste 1 : chnger le JS pour ne pas se baser sur le name

Je suis pas convaincu que l'on obtiendra un JS plus robuste. En effet, le but du JS d'afficher_si c'est notamment d'obtenir "la valeur qui serait posté par le formulaire si on le soumettait maintenant". C'est le role de la fonction https://api.jquery.com/serializearray/.

Or, si on ne passe pas par le name, il faut chercher cette valeur autrement, et c'est là que ca se complique car selon le type de champ, on ne doit pas chercher la même chose. Exemple sans name (par ex sur id)

  • ligne de texte, pour avoir la valeur : $('input#id').val()
  • bouton radio, pour avoir la valeur : $('champ_identifiant:checked').val()

On doit donc avoir un JS qui varie considérablement selon les type de saisie, sachant qu'on peut difficilement déterminer précisement à l'avance. C'est ce qu'on faisait avant la simplification du début d'année. Et ca posait plein de problème. Donc non je vois pas concrètement comment faire sans se baser sur les names, sauf à recomplexifier le JS. (ping @rastapopoulos).

Piste 2 : adapter dynamiquement les attributs data-afficher-si

A Exemple de code

Pour faire droit à la demande de JS, je te fournis ici le code HTML generé pour le formidable formidable que j'ai posté tout à l'heure (formulaire-nospam.yaml).

α Si l'obsfuscation n'est pas active.

<div class="editer-groupe">
               
               
                    <!--!inserer_saisie_editer-->
        <div class="editer editer_input_1 saisie_input editer_odd" data-id="@60fab32052e2e">
           
            <label class="label" for="champ_input_1">Conditionnante</label>

           
           
           

           
            <input type="text" name="input_1" class="text" id="champ_input_1" size="40">

           
           

           
            </div>



<!--!inserer_saisie_editer-->
        <div class="editer editer_input_2 saisie_input editer_even afficher_si_visible" data-id="@60fab32262aae" data-afficher_si="afficher_si({&quot;champ&quot;:&quot;input_1&quot;,&quot;total&quot;:&quot;&quot;,&quot;operateur&quot;:&quot;==&quot;,&quot;valeur&quot;:&quot;oui&quot;})" style="">
           
            <label class="label" for="champ_input_2">Conditionnée</label>

           
           
           

           
            <input type="text" name="input_2" class="text" id="champ_input_2" size="40">

           
           

           
            </div>
                <div style="display:none;">
                    <label for="mechantrobot-24">Veuillez laisser ce champ vide&nbsp;:</label>
                    <input type="text" id="mechantrobot-24" name="mechantrobot" value="">
                </div>
            </div>

β Si j'active l'obfuscation

<div class="editer-groupe">
               
               
                    <!--!inserer_saisie_editer-->
        <div class="editer saisie_session_email" style="display: none;">
    <label for="give_me_your_email">Veuillez laisser ce champ vide&nbsp;:</label>
    <input type="text" class="text email" name="x_MDIzS3kzZERyaVdQVWcxenlHMD0" id="give_me_your_email" value="" size="10">
</div><div class="editer editer_input_1 saisie_input editer_odd" data-id="@60fab32052e2e">
           
            <label class="label" for="champ_input_1">Conditionnante</label>

           
           
           

           
            <input type="text" name="x_MDIzS3gzUlNzajJQRFE9PQ" class="text" id="champ_input_1" size="40">

           
           

           
            </div>



<!--!inserer_saisie_editer-->
        <div class="editer editer_input_2 saisie_input editer_even afficher_si_masque_chargement afficher_si_masque" data-id="@60fab32262aae" data-afficher_si="afficher_si({&quot;champ&quot;:&quot;input_1&quot;,&quot;total&quot;:&quot;&quot;,&quot;operateur&quot;:&quot;==&quot;,&quot;valeur&quot;:&quot;oui&quot;})" style="display: none;" aria-hiden="true">
           
            <label class="label" for="champ_input_2">Conditionnée</label>

           
           
           

           
            <input type="text" name="x_MDIzS3gzUlNzajJQRGc9PQ" class="text" id="champ_input_2" size="40">

           
           

           
            </div>
                <div style="display:none;">
                    <label for="mechantrobot-24">Veuillez laisser ce champ vide&nbsp;:</label>
                    <input type="text" id="mechantrobot-24" name="x_MDIzS3czOUJyeWkrU0JCK3hYYmQ" value="">
                </div>
            </div>

γ Ce qu'il faudrait obtenir comme HTML

<div class="editer-groupe">
               
               
                    <!--!inserer_saisie_editer-->
        <div class="editer saisie_session_email" style="display: none;">
    <label for="give_me_your_email">Veuillez laisser ce champ vide&nbsp;:</label>
    <input type="text" class="text email" name="x_MDIzS3kzZERyaVdQVWcxenlHMD0" id="give_me_your_email" value="" size="10">
</div><div class="editer editer_input_1 saisie_input editer_odd" data-id="@60fab32052e2e">
           
            <label class="label" for="champ_input_1">Conditionnante</label>

           
           
           

           
            <input type="text" name="x_MDIzS3gzUlNzajJQRFE9PQ" class="text" id="champ_input_1" size="40">

           
           

           
            </div>



<!--!inserer_saisie_editer-->
        <div class="editer editer_input_2 saisie_input editer_even afficher_si_masque_chargement afficher_si_masque" data-id="@60fab32262aae" data-afficher_si="afficher_si({&quot;champ&quot;:&quot;x_MDIzS3gzUlNzajJQRFE9PQ&quot;,&quot;total&quot;:&quot;&quot;,&quot;operateur&quot;:&quot;==&quot;,&quot;valeur&quot;:&quot;oui&quot;})" style="display: none;" aria-hiden="true">
           
            <label class="label" for="champ_input_2">Conditionnée</label>

           
           
           

           
            <input type="text" name="x_MDIzS3gzUlNzajJQRGc9PQ" class="text" id="champ_input_2" size="40">

           
           

           
            </div>
                <div style="display:none;">
                    <label for="mechantrobot-24">Veuillez laisser ce champ vide&nbsp;:</label>
                    <input type="text" id="mechantrobot-24" name="x_MDIzS3czOUJyeWkrU0JCK3hYYmQ" value="">
                </div>
            </div>

δ Synthèse

Il faut adapter le data-afficher_si pour y remplacer le input_1 par x_MDIzS3gzUlNzajJQRFE9PQ.

Comment faire ?

α Piste 2α

C'est celle que tu propose, avoir des balises qui permettent de retrouver le name obfusqué et/ou passer le jeton à l'environnement.

Dans mon cas concret, vu que je passe par un filtre, il faudrait que j'envoie le jeton à l'environnement de chacune de mes saisies. Les limites que je vois sont les suivantes :

  • Il faudrait modifier les quelques plugins qui ont des saisies autonomes pour que cela marche avec les leurs (mais bon c'est assez facile à trouver)
  • On multiplie les caches, puisqu'on rajoute des env

β Piste 2β

C'est celle que je proposais, modulo tes remarques sur "le bon lieu où se brancher". A savoir : une fois que les name ont été remplacés par nospam_encrypt_form_names, pouvoir faire aussi d'autre remplacement.

Avantage : souplesse
Inconvienent : on doit faire des regepx à tire la rigot.

En plus c'est pas si simple que cela a impléementé, car

  • soit on ajoute le pipeline que je suggérais
  • soit doit faire remonter les équivalences depuis nospam_encrypt_form_names vers nospam_formulaire_fond pour pouvoir ensuite les passer à la suite du flux

Conclusion

Dans tous les cas c'est complexe... salté de spammeurs

A oui. Je suis un peu perdu, car j'avais un comportement étrange que je viens de comprendre. Je ne comprenais pas pourquoi mon test rapide semblait marchait, mais n'était pas une bonne idée. Si dans un même hit on fait ``` nospam_name_encode('un_name'); //puis plus loin nospam_name_encode('un_name','unjeton'); ``` Et bien le resultat sera le même dans les deux cas, à cause du `static $private_key` dans `nospam_private_key()`. C'est que mon test un peu rapide l'était trop. Il s'agissait d'appeler `nospam_name_encode()`, sans jeton explicite, dans la fonction qui genere le data-afficher_si, laquelle est appelée AVANT `nospam_encrypt_form_names`. Mais évidemment avec cela on perd tout l'intérêt du chiffrement, puisque du coup on n'a plus de jeton. => Mon doute était fondé, même si j'arrivé pas à comprendre pourquoi => Il faut donc tenir systématiquent compte du jeton pour l'encryptage. Je reprend sur les pistes pour mon problème. # Piste 1 : chnger le JS pour ne pas se baser sur le name Je suis pas convaincu que l'on obtiendra un JS plus robuste. En effet, le but du JS d'afficher_si c'est notamment d'obtenir "la valeur qui serait posté par le formulaire si on le soumettait maintenant". C'est le role de la fonction https://api.jquery.com/serializearray/. Or, si on ne passe pas par le name, il faut chercher cette valeur autrement, et c'est là que ca se complique car selon le type de champ, on ne doit pas chercher la même chose. Exemple sans name (par ex sur id) - ligne de texte, pour avoir la valeur : `$('input#id').val()` - bouton radio, pour avoir la valeur : `$('champ_identifiant:checked').val()` On doit donc avoir un JS qui varie considérablement selon les type de saisie, sachant qu'on peut difficilement déterminer précisement à l'avance. C'est ce qu'on faisait avant la simplification du début d'année. Et ca posait plein de problème. Donc non je vois pas concrètement comment faire sans se baser sur les names, sauf à recomplexifier le JS. (ping @rastapopoulos). # Piste 2 : adapter dynamiquement les attributs data-afficher-si ## A Exemple de code Pour faire droit à la demande de JS, je te fournis ici le code HTML generé pour le formidable formidable que j'ai posté tout à l'heure (formulaire-nospam.yaml). ### α Si l'obsfuscation n'est pas active. ``` <div class="editer-groupe"> <!--!inserer_saisie_editer--> <div class="editer editer_input_1 saisie_input editer_odd" data-id="@60fab32052e2e"> <label class="label" for="champ_input_1">Conditionnante</label> <input type="text" name="input_1" class="text" id="champ_input_1" size="40"> </div> <!--!inserer_saisie_editer--> <div class="editer editer_input_2 saisie_input editer_even afficher_si_visible" data-id="@60fab32262aae" data-afficher_si="afficher_si({&quot;champ&quot;:&quot;input_1&quot;,&quot;total&quot;:&quot;&quot;,&quot;operateur&quot;:&quot;==&quot;,&quot;valeur&quot;:&quot;oui&quot;})" style=""> <label class="label" for="champ_input_2">Conditionnée</label> <input type="text" name="input_2" class="text" id="champ_input_2" size="40"> </div> <div style="display:none;"> <label for="mechantrobot-24">Veuillez laisser ce champ vide&nbsp;:</label> <input type="text" id="mechantrobot-24" name="mechantrobot" value=""> </div> </div> ``` ### β Si j'active l'obfuscation ```` <div class="editer-groupe"> <!--!inserer_saisie_editer--> <div class="editer saisie_session_email" style="display: none;"> <label for="give_me_your_email">Veuillez laisser ce champ vide&nbsp;:</label> <input type="text" class="text email" name="x_MDIzS3kzZERyaVdQVWcxenlHMD0" id="give_me_your_email" value="" size="10"> </div><div class="editer editer_input_1 saisie_input editer_odd" data-id="@60fab32052e2e"> <label class="label" for="champ_input_1">Conditionnante</label> <input type="text" name="x_MDIzS3gzUlNzajJQRFE9PQ" class="text" id="champ_input_1" size="40"> </div> <!--!inserer_saisie_editer--> <div class="editer editer_input_2 saisie_input editer_even afficher_si_masque_chargement afficher_si_masque" data-id="@60fab32262aae" data-afficher_si="afficher_si({&quot;champ&quot;:&quot;input_1&quot;,&quot;total&quot;:&quot;&quot;,&quot;operateur&quot;:&quot;==&quot;,&quot;valeur&quot;:&quot;oui&quot;})" style="display: none;" aria-hiden="true"> <label class="label" for="champ_input_2">Conditionnée</label> <input type="text" name="x_MDIzS3gzUlNzajJQRGc9PQ" class="text" id="champ_input_2" size="40"> </div> <div style="display:none;"> <label for="mechantrobot-24">Veuillez laisser ce champ vide&nbsp;:</label> <input type="text" id="mechantrobot-24" name="x_MDIzS3czOUJyeWkrU0JCK3hYYmQ" value=""> </div> </div> ```` ### γ Ce qu'il faudrait obtenir comme HTML ``` <div class="editer-groupe"> <!--!inserer_saisie_editer--> <div class="editer saisie_session_email" style="display: none;"> <label for="give_me_your_email">Veuillez laisser ce champ vide&nbsp;:</label> <input type="text" class="text email" name="x_MDIzS3kzZERyaVdQVWcxenlHMD0" id="give_me_your_email" value="" size="10"> </div><div class="editer editer_input_1 saisie_input editer_odd" data-id="@60fab32052e2e"> <label class="label" for="champ_input_1">Conditionnante</label> <input type="text" name="x_MDIzS3gzUlNzajJQRFE9PQ" class="text" id="champ_input_1" size="40"> </div> <!--!inserer_saisie_editer--> <div class="editer editer_input_2 saisie_input editer_even afficher_si_masque_chargement afficher_si_masque" data-id="@60fab32262aae" data-afficher_si="afficher_si({&quot;champ&quot;:&quot;x_MDIzS3gzUlNzajJQRFE9PQ&quot;,&quot;total&quot;:&quot;&quot;,&quot;operateur&quot;:&quot;==&quot;,&quot;valeur&quot;:&quot;oui&quot;})" style="display: none;" aria-hiden="true"> <label class="label" for="champ_input_2">Conditionnée</label> <input type="text" name="x_MDIzS3gzUlNzajJQRGc9PQ" class="text" id="champ_input_2" size="40"> </div> <div style="display:none;"> <label for="mechantrobot-24">Veuillez laisser ce champ vide&nbsp;:</label> <input type="text" id="mechantrobot-24" name="x_MDIzS3czOUJyeWkrU0JCK3hYYmQ" value=""> </div> </div> ``` ### δ Synthèse Il faut adapter le data-afficher_si pour y remplacer le `input_1` par `x_MDIzS3gzUlNzajJQRFE9PQ`. ## Comment faire ? ### α Piste 2α C'est celle que tu propose, avoir des balises qui permettent de retrouver le name obfusqué et/ou passer le jeton à l'environnement. Dans mon cas concret, vu que je passe par un filtre, il faudrait que j'envoie le jeton à l'environnement de chacune de mes saisies. Les limites que je vois sont les suivantes : - Il faudrait modifier les quelques plugins qui ont des saisies autonomes pour que cela marche avec les leurs (mais bon c'est assez facile à trouver) - On multiplie les caches, puisqu'on rajoute des env ### β Piste 2β C'est celle que je proposais, modulo tes remarques sur "le bon lieu où se brancher". A savoir : une fois que les name ont été remplacés par `nospam_encrypt_form_names`, pouvoir faire aussi d'autre remplacement. Avantage : souplesse Inconvienent : on doit faire des regepx à tire la rigot. En plus c'est pas si simple que cela a impléementé, car - soit on ajoute le pipeline que je suggérais - soit doit faire remonter les équivalences depuis `nospam_encrypt_form_names` vers `nospam_formulaire_fond` pour pouvoir ensuite les passer à la suite du flux ### Conclusion Dans tous les cas c'est complexe... salté de spammeurs
Poster
Collaborator

Corrigenda : l'option de passage post nospam_encrypt_form_names ne necessite ps, dans mon cas, de regepx en plus, un str_replace suffirait, a priori.

Corrigenda : l'option de passage post `nospam_encrypt_form_names` ne necessite ps, dans mon cas, de regepx en plus, un str_replace suffirait, a priori.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.