Produits Entr'ouvert » w.c.s.

Si je comprends, en guise d'authentification, le lien aurait juste un "token" (avec une durée de validité) ?

Dans ce cas, toute personne qui clique dessus pourra lancer l'action. C'est pratique mais pas très sécure, faut en être bien bien conscient (typiquement, si le mail est transféré, etc).

Autre soucis dans la demande : comment insérer le lien dans le mail, et comment dire quelle action il effectue ? Quelles actions vois-tu ? pour ma part je ne vois que des sauts...?

(Et sinon, juste pour savoir, qui fait cette demande ?)

Perso je suis assez opposé à l'idée de déclencher une action sur base de l'accès (GET) à une URL, il peut trop facilement y avoir un accès automatique, pour vérifier qu'il n'y a pas de malware au bout, pour afficher une prévisu en tooltip, ce genre de trucs, qui font qu'il faut absolument pour moi passer par du POST.

En ce qui concerne les autorisations, j'imaginais en première lecture que les accès se faisaient quand même par des personnes authentifiées, ça m'effraierait assez que ce ne soit pas le cas. Et dans cette situation, les rôles existants suffisent, et on pourrait individuellement, bouton de transition par bouton de transition, avoir des URL qui afficheraient l'action et un bouton de validation. Celles-ci pourraient alors simplement être placées dans le mail (si l'objectif est de ne pas encombrer l'affichage par toute l'interface de backoffice).

Frédéric Péters a écrit :

Perso je suis assez opposé à l'idée de déclencher une action sur base de l'accès (GET) à une URL, il peut trop facilement y avoir un accès automatique, pour vérifier qu'il n'y a pas de malware au bout, pour afficher une prévisu en tooltip, ce genre de trucs, qui font qu'il faut absolument pour moi passer par du POST.

Il peut y avoir un mix : un GET (avec le token) amène sur une page qui demande à la personne de valider sa demande d'action (via un POST).

Pourquoi pas, mais il faudrait que la fonction ne soit donnée que sur la demande liée, et rien d'autre... pas si simple.

Et il faudrait aussi éviter que les moteurs de recherche "cliquent" sur le lien (oui gmail je pense à toi), et se retrouvent devant des données perso (surtout dans le cas dont on parle au cd59, "professionnel de santé", tout est dit). Ça pourrait se passer par un machin genre captcha.

Bon alors c'est peut-être plus simple de repartir du principe des trackings codes et de le muscler:

• avoir plusieurs tracking codes
• pour un tracking code pouvoir désigner le rôle que ça représente, pas forcément demandeur

Dans le mail on met un lien et le tracking code, la personne doit le retapper, impossible que Google suive ça automatiquement.

Oui bien on reste sur ça et on prévoit bêtement une page intermédiaire qui prévient de ce qui se passe et exige un POST de validation "Great power, great responsibility tout ça", tu peux ranger ça dans la case captcha si tu veux, Google passera pas ça non plus.

Sinon, idée Benjamin :

On pourrait éventuellement étudier la possilité d'un formulaire HTML, ie d'une action par « POST » ... le risque est certainement moins grand selon
https://www.stonetemple.com/does-google-sniff-gmail-for-urls/

Benjamin Dauvergne a écrit :

Bon alors c'est peut-être plus simple de repartir du principe des trackings codes et de le muscler:

• avoir plusieurs tracking codes
• pour un tracking code pouvoir désigner le rôle que ça représente, pas forcément demandeur

Dans le mail on met un lien et le tracking code, la personne doit le retapper, impossible que Google suive ça automatiquement.

Oui bien on reste sur ça et on prévoit bêtement une page intermédiaire qui prévient de ce qui se passe et exige un POST de validation "Great power, great responsibility tout ça", tu peux ranger ça dans la case captcha si tu veux, Google passera pas ça non plus.

Je m'incruste dans la réflexion:

1. mettre des FORM dans des émails est expérimental, il faut modifier le DOCTYPE, et les résultats ne sont pas encourageants : https://github.com/massimo-cassandro/email-forms-test
2. mettre des mailto
3. j'abonde pour le fonctionnement proposé dans le message#6 de Benjamin, et qui est très courant. Un lien pour le CTA dans l’émail (avec un token de validation) qui aboutit sur un FORM de réponse éphémère dans le navigateur (avec si besoin un couche de validation supplémentaire genre demander le numéro de suivi, ou reconfirmer son nom de famille ou son email, voir même un captcha)

Dans ce dernier cas, trois bonnes pratiques d'implémentation sont:

1. 1 email = 1 demande à l'utilisateur
2. le sujet du mail = l'action
3. 1 email = 1 lien CTA

En extra, pour augmenter le taux de réponse (si c'est pas déjà le cas... désolé je débarque):

1. inclure dans l'email une capture ou un GIF de l'interface du FORM qu'on demande à l'utilisateur de consulter pour lui montrer qu'on va pas le manger
2. confirmer la validation de l'envoir du FORM avec un émail de remerciements avec un résumé des données entrées et les étapes à venir.

Voilà, si ça peut servir

D'une discussion aujourd'hui,

• ajout d'un identifiant (optionnel) aux actions de saut manuel
• templatetag / directive restructuredtext / que sais-je, pour inclure un lien stylé bouton dans un email
• page de destination affichant juste le nom du formulaire et le libellé de l'action
• sur POST exécution du workflow

Frédéric Péters a écrit :

Comme question à un moment je me suis demandé si dans le jeton, puis passer l'info dans le workflow, il y aurait sens à mentionner la liste des destinataires de l'email, mais je n'ai rien fait ça à ce sujet.

Je dirai que ça pourrait être bien, mais mieux si une session est ouverte vérifier qu'elle a les droits nécessaire pour l'action et prendre en compte l'identité de la personne exacte pour l'action et peut-être même pas demander de confirmation via POST dans ce cas. En fait je me demande l'intérêt de ne pas exiger d'authentification par défaut; que pour certains boutons l'action soit possible par un quidam et juste lui, mais dans le cas d'un mail envoyé à un rôle, c'est peut-être mieux que l'agent se connecte.

Une fois le jeton consommé, est-ce qu'on ne le marquerait comme étant usé (idéalement on devrait avoir un jeton par mail pour toutes les actions mais bon) ? Ici on va s'en sortir parce que pour un identifiant d'action donné suite au saut on ne devrait plus trouver les mêmes actions et donc TraversalError.

PS: aussi ça aurait été bien de pouvoir envoyer un mail par user/email et de coder cette information dans le lien en plus du numéro du jeton, mais j'en parle juste pour un monde idéal, ton patch fait largement le job.

Je dirai que ça pourrait être bien, mais mieux si une session est ouverte vérifier qu'elle a les droits nécessaire pour l'action et prendre en compte l'identité de la personne exacte pour l'action et peut-être même pas demander de confirmation via POST dans ce cas. En fait je me demande l'intérêt de ne pas exiger d'authentification par défaut; que pour certains boutons l'action soit possible par un quidam et juste lui, mais dans le cas d'un mail envoyé à un rôle, c'est peut-être mieux que l'agent se connecte.

Cet envoi il est fait pour des personnes qui veulent agir sans se connecter (la description du ticket est d'époque); maintenant on peut s'interroger sur le comportement quand c'est exploité par des agents connectés mais peut-être ailleurs ? (il y aurait par exemple à faire un retour vers la demande / un listing, après l'action, genre)

Une fois le jeton consommé, est-ce qu'on ne le marquerait comme étant usé (idéalement on devrait avoir un jeton par mail pour toutes les actions mais bon) ? Ici on va s'en sortir parce que pour un identifiant d'action donné suite au saut on ne devrait plus trouver les mêmes actions et donc TraversalError.

Il y a bien une suppression du jeton une fois l'action exécutée (self.token.remove_self()).