Project

General

Profile

Actions

Anomalie #1659

closed

L'envoi d'images 'inline' devrait être désactivé

Added by Michael Charaoui over 1 year ago. Updated about 1 year ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
11/29/2022
Due date:
% Done:

100%

Estimated time:
Version utilisée:

Description

Sun serveur dédié VPS chez LWS tout neuf j'ai alors installé la galette sur une serveur Apache2.2 + PHP version 8.1

J'ai appliqué un précédent correctif et effectivement cela permet de faire fonctionner quasiment complètement l'envoie mailing avec serveur PHP (PHP-FPM avec PHP 8.1 sous ISP_Config) sauf pour le cas suivant :
Je créer un nouvel Envoi et laissant interpréter les balises html cochées et je veux mettre une image dans mon email via l'icône image et je choisi un fichier sur mon disque dur que je souhaite inclure dans mon mail.
Je clique sur envoyer une fois l'image mise et j'ai alors le message suivant " Erreur de l’application " qui s'affiche.
Dans le log erreur apache j'ai:

[Tue Nov 29 12:04:54.787046 2022] [proxy_fcgi:error] [pid 82951] [client mon_adresse_ip:50978] AH01071: Got error 'PHP message: Galette error:\nType: PDOException\nCode: 22001\nMessage: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'mailing_body' at row 1\nFile: /var/www/clients/client1/web1/web/gestion/vendor/laminas/laminas-db/src/Adapter/Driver/Pdo/Connection.php\nLine: 376\nTrace: #0 /var/www/clients/client1/web1/web/gestion/vendor/laminas/laminas-db/src/Adapter/Driver/Pdo/Connection.php(376): PDO->query()\n#1 /var/www/clients/client1/web1/web/gestion/vendor/laminas/laminas-db/src/Adapter/Adapter.php(194): Laminas\\Db\\Adapter\\Driver\\Pdo\\Connection->execute()\n#2 /var/www/clients/client1/web1/web/gestion/lib/Galette/Core/Db.php(788): Laminas\\Db\\Adapter\\Adapter->query()\n#3 /var/www/clients/client1/web1/web/gestion/lib/Galette/Core/MailingHistory.php(450): Galette\\Core\\Db->execute()\n#4 /var/www/clients/client1/web1/web/gestion/lib/Galette/Core/MailingHistory.php(340): Galette\\Core\\MailingHistory->store()\n#5 /var/www/clients/client1/web1/web/gestion/lib/Galette/Controllers/Crud/...', referer: https://mon-domaine.fr/gestion/webroot/index.php/mailing?from=18
[Tue Nov 29 12:04:54.787139 2022] [proxy_fcgi:error] [pid 82951] [client mon_adresse_ip:50978] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in [no active file]:0\nStack trace:\n#0 {main}\n thrown in [no active file] on line 0', referrer: https://mon-domaine.fr/gestion/webroot/index.php/mailing?from=18

Par contre le mail part bien avec la pièce jointe mais il ne stock pas l'image dans le dossier attachments (j'ai vérifié les droits, ça ne change rien) et il ne stock pas non plus comme quoi il a envoyé le mail dans la page Envoi de la galette comme si je n'avais pas envoyé de mail.
Si j'envoie en pièce jointe ou sans image tout fonctionne

Actions #1

Updated by Johan Cwiklinski over 1 year ago

De ce que j'en comprends (pas le temps de tester), il essaie ici d'inclure l'image dans le corps du courriel, et non pas en pièce jointe. Je n'ai pas souvenir que ça ait été voulu, je pense que l'erreur vient de là.

Le fait que rien ne soit enregistré dans le dossier attachments semble parfaitement normal dans ce cas, et vu que ce n'est normalement pas prévu, l'erreur en base semble légitime elle aussi.

Je ne pense pas que la version de PHP entre en ligne de compte.

Actions #2

Updated by Michael Charaoui over 1 year ago

Johan Cwiklinski a écrit (#note-1):

De ce que j'en comprends (pas le temps de tester), il essaie ici d'inclure l'image dans le corps du courriel, et non pas en pièce jointe. Je n'ai pas souvenir que ça ait été voulu, je pense que l'erreur vient de là.

Le fait que rien ne soit enregistré dans le dossier attachments semble parfaitement normal dans ce cas, et vu que ce n'est normalement pas prévu, l'erreur en base semble légitime elle aussi.

Je ne pense pas que la version de PHP entre en ligne de compte.

Quand on clique sur l'icône Picture (image) qui permet d'ajouter une image dans l'email il est bien demandé le fichier image sous deux formes, soit on choisi des fichiers directement de son PC, soit on met l'url d'une image sur le web

Si on clique en haut sur "Ajouter une pièce jointe" alors la cela fonctionne

Actions #3

Updated by Johan Cwiklinski over 1 year ago

  • Subject changed from Bug envoie courriel avec PHP8.1 to L'envoi d'images 'inline' devrait être désactivé

Michael Charaoui a écrit (#note-2):

Quand on clique sur l'icône Picture (image) qui permet d'ajouter une image dans l'email il est bien demandé le fichier image sous deux formes, soit on choisi des fichiers directement de son PC, soit on met l'url d'une image sur le web

Si on clique en haut sur "Ajouter une pièce jointe" alors la cela fonctionne

OK, c'est bien ce que je pensais alors... Galette n'a jamais permis d'ajouter une image directement, ce n'est pas prévu. Je présume qu'il s'agit du'ne fonctionnalité active par défaut dans l'éditeur HTML, il faudra la désactiver.

Actions #4

Updated by Guillaume AGNIERAY over 1 year ago

Johan Cwiklinski a écrit (#note-3):

Michael Charaoui a écrit (#note-2):

Quand on clique sur l'icône Picture (image) qui permet d'ajouter une image dans l'email il est bien demandé le fichier image sous deux formes, soit on choisi des fichiers directement de son PC, soit on met l'url d'une image sur le web

Si on clique en haut sur "Ajouter une pièce jointe" alors la cela fonctionne

OK, c'est bien ce que je pensais alors... Galette n'a jamais permis d'ajouter une image directement, ce n'est pas prévu. Je présume qu'il s'agit du'ne fonctionnalité active par défaut dans l'éditeur HTML, il faudra la désactiver.

Le nouvel éditeur permet effectivement d'insérer des images dans le corps du mail de 2 façons :
  1. en choisissant un fichier sur son PC ; l'image est alors encodée en base64 dans le src de l'image. Je pensais initialement que cette fonctionnalité serait utile (#1568), mais dans certains cas, le corps du message devenu trop long dépasse de toute évidence la limite d'enregistrement dans le champ TEXT de la base de données :/
  2. en donnant l'URL d'une image hébergée ; cette URL est alors directement utilisée dans le src de l'image. Cette méthode ne devrait pas engendrer le problème (ou en tout cas dans une moindre mesure, et à moins d'URLs multiples à rallonge et/ou d'un message déjà particulièrement très très long) ; on peut de toute façon déjà utiliser cette méthode sans passer par l'éditeur.
Quelle(s) solution(s) serait-il préférable de mettre en œuvre ?
  • désactiver le choix du fichier sur son PC tout en conservant la possibilité d'insérer des images hébergées,
  • intercepter la taille brute du corps du message avant l'enregistrement et avertir l'utilisateur en cas de dépassement,
  • changer le type du champ mailing_body de la table mailing_history dans la base de données (MEDIUMTEXT, LONGTEXT ?),
  • désactiver totalement l'insertion d'images dans l'éditeur.
Actions #5

Updated by Guillaume AGNIERAY over 1 year ago

Guillaume Agniéray a écrit (#note-4):

Quelle(s) solution(s) serait-il préférable de mettre en œuvre ?
  • désactiver le choix du fichier sur son PC tout en conservant la possibilité d'insérer des images hébergées,
  • intercepter la taille brute du corps du message avant l'enregistrement et avertir l'utilisateur en cas de dépassement,
  • changer le type du champ mailing_body de la table mailing_history dans la base de données (MEDIUMTEXT, LONGTEXT ?),
  • désactiver totalement l'insertion d'images dans l'éditeur.

Changer le type du champ en MEDIUMTEXT (16MB contre 64KB pour le type TEXT) permettrait l'utilisation d'images en base64 dans le code HTML du message.

Mais, bien conscient que Galette n'est pas un outil d'emailing, conserver cette possibilité conduira inévitablement à des abus et mauvais usages en la matière, et donc à toute une série de remontées d'anomalies liées à la non délivrabilité des messages envoyés, voire des demandes d'évolutions pour étendre les possibilités d'utilisation d'images dans le corps des messages.

Mieux vaut donc s'épargner cette peine.

Désactiver les images en base64 dans l'éditeur devrait être suffisant. Mais je pense qu'on peut conserver la possibilité d'insérer des images hébergées pour ceux qui ne maîtrisent pas le HTML, et parce que rien ne l'empêche de toute façon lorsqu'on n'active pas l'éditeur.

Actions #6

Updated by Johan Cwiklinski over 1 year ago

Guillaume Agniéray a écrit (#note-5):

Guillaume Agniéray a écrit (#note-4):

Quelle(s) solution(s) serait-il préférable de mettre en œuvre ?
  • désactiver le choix du fichier sur son PC tout en conservant la possibilité d'insérer des images hébergées,
  • intercepter la taille brute du corps du message avant l'enregistrement et avertir l'utilisateur en cas de dépassement,
  • changer le type du champ mailing_body de la table mailing_history dans la base de données (MEDIUMTEXT, LONGTEXT ?),
  • désactiver totalement l'insertion d'images dans l'éditeur.

Changer le type du champ en MEDIUMTEXT (16MB contre 64KB pour le type TEXT) permettrait l'utilisation d'images en base64 dans le code HTML du message.

Mais, bien conscient que Galette n'est pas un outil d'emailing, conserver cette possibilité conduira inévitablement à des abus et mauvais usages en la matière, et donc à toute une série de remontées d'anomalies liées à la non délivrabilité des messages envoyés, voire des demandes d'évolutions pour étendre les possibilités d'utilisation d'images dans le corps des messages.

Mieux vaut donc s'épargner cette peine.

Désactiver les images en base64 dans l'éditeur devrait être suffisant. Mais je pense qu'on peut conserver la possibilité d'insérer des images hébergées pour ceux qui ne maîtrisent pas le HTML, et parce que rien ne l'empêche de toute façon lorsqu'on n'active pas l'éditeur.

J'avais vu ton commentaire, mais pas encore eu le temps d'y répondre. J'en étais arrivé à la même conclusion :) Supprimons juste les images base64 pour corriger le problème d'origine facilement, ce sera bien assez.

Actions #7

Updated by Guillaume AGNIERAY over 1 year ago

  • Status changed from Nouveau to Résolu
  • % Done changed from 0 to 100
Actions #8

Updated by Johan Cwiklinski over 1 year ago

  • Target version set to 1.0.0
Actions #9

Updated by Johan Cwiklinski about 1 year ago

  • Status changed from Résolu to Fermé
Actions

Also available in: Atom PDF