Bonjour à toustes,
J’ai publié plusieurs sites web (statiques ou non) pour Jean-Cloud, et j’ai dû inclure dans chacun d’eux un formulaire de contact.
Pour ne pas réinventer la roue, j’ai créé un petit ensemble python+js+html/css qui permet de créer des formulaires assez rapidement sans avoir à redéployer le se code serveur. Rien de très poussé mais c’est là que l’idée a commencée.
En gros ce logiciel est aux formulaires de contact ce que discourse est aux forums.
Le git est ici : https://git.jean-cloud.net/adrian/contact-mailer
Le temps est venu de passer de la preuve de concept pleine de bugs à un logiciel bien testé mais ça me coûterai de le faire juste pour mes trois sites…
Le principe serait le suivant :
- Un chaton héberge le service
- L’administrateur peut y créer un compte pour un webmaster (ou le service peut se baser sur LDAP, openID…)
- Le webmaster peut y créer un formulaire
- Le webmaster peut ensuite copier une ligne de js ou son formulaire html sur son site.
- Les visiteurs remplissent le formulaire
- Il est envoyé (http post) à notre service mail
- Qui l’envoie par mail au webmaster
Les avantages de ce logiciel :
- Créer un formulaire devient assez simple
- Peu de config nécessaire
- Permet de faire les choses une fois et bien ! (Sécurité et accessibilité du formulaire, capcha et anti-capcha…)
- Une instance peut servir pas mal de monde #mutualisation #économie$
- On peut imaginer des variantes sympa comme un bouton « Cette fonctionnalité est cassée » à placer partout sur nos appli mal testées
Les limites du logiciel :
- Le spam
- C’est du temps pour bien le coder et le maintenir
- Le spam
Donc premièrement, est-ce que ce service existe déjà ou presque déjà en logiciel libre de qualité ? Parce que j’ai sûrement mal cherché…
Ensuite, s’il n’existe pas vraiment, est-ce que quelqu’un·e serait intéressé·e pour l’utiliser et/ou héberger son instance perso ? Histoire de savoir si je me lance dans l’aventure.
Si c’est le cas, quelles fonctionnalités vous sembleraient importantes ? D’un point de vue d’hébergeureuses et d’utilisateurices de ces formulaires ?
Et si ce service est désiré, est-ce que quelqu’un·e a envie de participer à sa conception, aux tests…
J’espère avoir été clair, sinon n’hésitez pas à demander des précisions !
Merci pour votre lecture et pour votre travail de chaton en général,
Jean-Cloud
2 « J'aime »
L’idée est sympa, et j’ai déjà une infra python. Avec quelques changement je pourrais en proposer une instance.
il y a juste un petit truc qui me chagrine: Pourquoi un mongodb ? un sqlite serait suffisant et est bien plus simple a gérer (la base de donnée est bien structuré, pas besoin d’une bdd orienté documents)
Un autre petit problème est que l’adresse mail viens du formulaire. Une façon de faire plus sympa serait de la dériver du token. Du coup ça simplifierais la gestion du spam (puisqu’il n’y aurait qu’une whitelist d’adresse). En gros quand on donne le token, on sait a quel domaine est destiné ce mail et du coup on contacte la/les adresses de contacte du domain.
Pour les features sympa a ajouter:
- une petite gui d’administration (pour gérer les token des utilisateurs etc)
- peut être un captcha d’une forme simple pour limiter le SPAM (genre écrire en tout lettres une de calcul simple et demander a l’utilisateur d’entrer
- avoir un vrai fichier de conf (regarde du coté de https://docs.python.org/3/library/configparser.html) pour simplifier l’administration
- permettre d’envoyer les mails a travers un serveur SMTP (j’ai du mal a voir si tu le fait ou si tu envois directement le mail dans ton code)
PS: ça fait longtemps que je dois développer un logiciel similaire mais que j’ai la flemme de le faire ><
Merci pour tes réponses et questions techniques ! Pour le sujet je vais retenir que tu es intéressé·e par l’idée. Ce code est un POC sale dont les choix techniques vont tous être requestionnés en fonction des besoins et des développeureuses.
J’avais utilisé mongodb parce que je voulais essayer la techno et que j’en extrais surtout du json. Je me suis dit « stocker du json => Mongodb ».
Le sqlite me convient tout autant pour la taille de la base. On peut imaginer du postresql pour de grosses bases.
L’adresse mail est stockée dans la base de donnée, dans la même entrée que le token. Je ne veux pas faire un service ouvert d’envoi de spam (les seules adresses que l’on peut spammer l’ont accepté…). On fait une whitelist de token au final.
- Une GUI d’administration est en développement
- Des capchas sont en cours d’ajout (écrire un texte simple). Un capchas inversé aussi (des calculs à faire pour augmenter le coût du spam).
- Pourquoi pas un fichier de conf. Pour le moment c’est un .env
- On utilise bien un serveur SMTP externe.