Le post en tant qu'invité plante lamentablement

Darks commented

2019-12-03 15:16:07 +01:00

Owner

C'est pas implémenté. À faire donc.

Darks added the

bug

label 2019-12-03 15:16:08 +01:00

Eragon commented

2020-01-29 12:11:24 +01:00

Member

Comment on implémente ça ?
On crée un utilisateur invité à qui on attribue les posts ?
Ou on joue avec le type d'utilisateur "Invité" de flask-login, pour ne pas avoir à ajouter un utilisateur par défaut à la bdd ?

Comment on gère la réattribution d'un post ? Genre je post alors que je n'ai pas de compte puis, un jour j'en crée un, et je demande la propriété de mes posts en invité. On fait comment ? Un admin va devoir le faire à la main ? Un bouton ajouté au message des invités permet de demander l'attribution un post ?

Comment on implémente ça ? On crée un utilisateur invité à qui on attribue les posts ? Ou on joue avec le type d'utilisateur "Invité" de flask-login, pour ne pas avoir à ajouter un utilisateur par défaut à la bdd ? Comment on gère la réattribution d'un post ? Genre je post alors que je n'ai pas de compte puis, un jour j'en crée un, et je demande la propriété de mes posts en invité. On fait comment ? Un admin va devoir le faire à la main ? Un bouton ajouté au message des invités permet de demander l'attribution un post ?

Lephenixnoir commented

2020-01-29 17:44:20 +01:00

Owner

Les posts postés en invité sont attribués à une instance de Guest (on réutilise une instance existante si le nom et l'IP sont les mêmes, sinon on en crée une autre).

Si tu crées un compte, tu ne peux a priori pas réclamer les posts parce qu'il n'y a pas de preuve que c'est toi qui les as faits. Éventuellement si ton IP est identique à celle d'une partie des posts on peut te les attribuer, mais pas mieux.

Les posts postés en invité sont attribués à une instance de `Guest` (on réutilise une instance existante si le nom et l'IP sont les mêmes, sinon on en crée une autre). Si tu crées un compte, tu ne peux a priori pas réclamer les posts parce qu'il n'y a pas de preuve que c'est toi qui les as faits. Éventuellement si ton IP est identique à celle d'une partie des posts on peut te les attribuer, mais pas mieux.

Breizh commented

2020-01-29 17:46:45 +01:00

Member

On peut pas demander un mail pour les posts invités ? C'est assez courant, sur les blogs par exemple.

Lephenixnoir commented

2020-01-29 19:24:55 +01:00

Owner

Si effectivement, et d'ailleurs on le fait déjà en ce moment. Même si tu peux mettre n'importe quoi...

Eragon commented

2020-01-29 19:33:08 +01:00

Member

On peut déjà prendre la solution du mail pour attribuer les posts, et afficher une erreur si le mail est déjà utilisé en bdd.
Qu'est-ce que Guest ? Et comment gérer plusieurs instances de Guest ?

On peut déjà prendre la solution du mail pour attribuer les posts, et afficher une erreur si le mail est déjà utilisé en bdd. Qu'est-ce que `Guest` ? Et comment gérer plusieurs instances de `Guest` ?

Lephenixnoir commented

2020-01-29 19:48:23 +01:00

Owner

Pour la première question, /app/models/users.py. Pour la seconde, c'est juste deux objets différents de type Guest (deux entrées dans la bdd).

En gros, c'est facile :

Si au moment du post il y a déjà un invité avec les mêmes pseudo normalisé + email + IP, tu lui donnes le post.
Sinon, tu en crées un autre (g = Guest(...)) et tu lui donnes le post.

Après faut ajouter le post et l'utilisateur à la bdd et commit.

Pour la première question, `/app/models/users.py`. Pour la seconde, c'est juste deux objets différents de type `Guest` (deux entrées dans la bdd). En gros, c'est facile : * Si au moment du post il y a déjà un invité avec les mêmes pseudo normalisé + email + IP, tu lui donnes le post. * Sinon, tu en crées un autre (`g = Guest(...)`) et tu lui donnes le post. Après faut ajouter le post et l'utilisateur à la bdd et commit.

Darks commented

2020-01-29 21:21:53 +01:00

Author

Owner

Mais est-ce que finalement c'est si utile que ça de stocker l'IP de chaque invité ayant posté un message ?

En gros je me demande si remplacer l'IP par un token secret ne permettrait pas d'attribuer avec plus de fiabilité des posts, tout en étant compatible RGPD.

Dans le système que j'imagine, on met un champ « Pseudo » et un champ « Token ». Le pseudo est affiché, le token reste secret (il peut s'agir d'un email). On indique sous le token que ce dernier sert à faire valoir ses droits sur les données (récupération, édition, suppression), et donc que si il n'y en a pas vous renoncez à les faire valoir, et si y'en a un vous le gardez précieusement.

Quand un nouveau compte est créé avec un pseudo d'invité, on demande le token utilisé. Si des contenus matchent au niveau pseudo + token, on les associe au nouveau compte. Les autres restent attribués à des Guest, sauf action manuelle de la part d'un admin/modo qui adapterai en fonction de la situation (discussion avec le nouveau membre).

Autre méthode : on créé le compte, si ça matche avec un invité, on invite l'utilisateur a entrer en contact avec l'équipe de modération pour récupérer ses contenus. L'action est manuelle, et on peut s'adapter aux situations bizarre (pseudo squatté, plusieurs tokens, etc.). Niveau process d'inscription, ça change rien.

Avantages que j'y vois :

D'un point de vue données personnelles, on en stocke à peine, et l'utilisateur a le choix sur ce qu'il partage ou non.
On propose une manière efficace et béton de faire appliquer ses droits.
Si l'IP de l'utilisateur change, on peut quand même identifier des contenus avec une probabilité certaine, en vérifiant le-dit token.
On limite l'usurpation d'identité (je sais que dans mon bahut X a un compte au nom de Y, je peux faire un compte au nom de Y depuis le bahut et usurper son identité).

En ce qui concerne les logs de service et de sécurité (anti-spam, autre), je pensais utiliser de manière globale au site un InfluxDB ou Logstash, ou solution qui permet de faire de la rotation automatiquement. Comme ça les logs techniques sont séparés de la BDD, et en cas de pépin on garde ceintures, bretelles et parachute.

Mais est-ce que finalement c'est si utile que ça de stocker l'IP de chaque invité ayant posté un message ? En gros je me demande si remplacer l'IP par un `token` secret ne permettrait pas d'attribuer avec plus de fiabilité des posts, tout en étant compatible RGPD. Dans le système que j'imagine, on met un champ « Pseudo » et un champ « Token ». Le pseudo est affiché, le token reste secret (il peut s'agir d'un email). On indique sous le token que ce dernier sert à faire valoir ses droits sur les données (récupération, édition, suppression), et donc que si il n'y en a pas vous renoncez à les faire valoir, et si y'en a un vous le gardez précieusement. Quand un nouveau compte est créé avec un pseudo d'invité, on demande le token utilisé. Si des contenus matchent au niveau pseudo + token, on les associe au nouveau compte. Les autres restent attribués à des Guest, sauf action manuelle de la part d'un admin/modo qui adapterai en fonction de la situation (discussion avec le nouveau membre). Autre méthode : on créé le compte, si ça matche avec un invité, on invite l'utilisateur a entrer en contact avec l'équipe de modération pour récupérer ses contenus. L'action est manuelle, et on peut s'adapter aux situations bizarre (pseudo squatté, plusieurs tokens, etc.). Niveau process d'inscription, ça change rien. Avantages que j'y vois : - D'un point de vue données personnelles, on en stocke à peine, et l'utilisateur a le choix sur ce qu'il partage ou non. - On propose une manière efficace et béton de faire appliquer ses droits. - Si l'IP de l'utilisateur change, on peut quand même identifier des contenus avec une probabilité certaine, en vérifiant le-dit token. - On limite l'usurpation d'identité (je sais que dans mon bahut X a un compte au nom de Y, je peux faire un compte au nom de Y depuis le bahut et usurper son identité). En ce qui concerne les logs de service et de sécurité (anti-spam, autre), je pensais utiliser de manière globale au site un InfluxDB ou Logstash, ou solution qui permet de faire de la rotation automatiquement. Comme ça les logs techniques sont séparés de la BDD, et en cas de pépin on garde ceintures, bretelles et parachute.

Breizh commented

2020-01-29 21:26:06 +01:00

Member

Si un invité veut faire valoir ses droits sur ses précédents messages, il avait qu'à s’inscrire avant… il suffit de préciser qu'un invité ne peut pas éditer ou assigner son message à un futur compte et hop. Bien plus simple à gérer. Et plus logique.

👍 1

Breizh commented

2020-01-29 21:37:27 +01:00

Member

Par contre faut prévoir un truc pour lutter contre le spam (volontaire/manuel, donc un captcha suffira pas) et le contournement de blocage.

Darks commented

2020-01-29 21:50:38 +01:00

Author

Owner

Si un invité veut faire valoir ses droits sur ses précédents messages, il avait qu'à s’inscrire avant… il suffit de préciser qu'un invité ne peut pas éditer ou assigner son message à un futur compte et hop. Bien plus simple à gérer. Et plus logique.

Ça t'a RGPD-ment pas le droit. Un utilisateur doit avoir un moyen d'accéder à ses données personnelles (et j'aurais tendance à dire qu'un pseudo + un message en est).

> Si un invité veut faire valoir ses droits sur ses précédents messages, il avait qu'à s’inscrire avant… il suffit de préciser qu'un invité ne peut pas éditer ou assigner son message à un futur compte et hop. Bien plus simple à gérer. Et plus logique. Ça t'a RGPD-ment pas le droit. Un utilisateur doit avoir un moyen d'accéder à ses données personnelles (et j'aurais tendance à dire qu'un pseudo + un message en est).

Lephenixnoir commented

2020-01-29 21:51:19 +01:00

Owner

Mais est-ce que finalement c’est si utile que ça de stocker l’IP de chaque invité ayant posté un message ?

Oui, non pas pour les identifier fonctionnellement sur le site, mais pour détecter les posts abusifs, les liers avec les IPs des membres inscrits, et traquer les trolls. C'est pas contraire au RGPD, et on peut les virer après 1 an si tu veux, ce qui m'intéresse c'est les informations dans l'immédiat.

Si un invité veut faire valoir ses droits sur ses précédents messages, il avait qu’à s’inscrire avant… il suffit de préciser qu’un invité ne peut pas éditer ou assigner son message à un futur compte et hop. Bien plus simple à gérer. Et plus logique.

+1. Concis et suffisant.

Autre méthode : on créé le compte, si ça matche avec un invité, on invite l’utilisateur a entrer en contact avec l’équipe de modération pour récupérer ses contenus. L’action est manuelle, et on peut s’adapter aux situations bizarre (pseudo squatté, plusieurs tokens, etc.).

Pour les rares cas où il est important de récupérer les données, je pense que c'est le bon plan. Mais comme une intervention manuelle est nécessaire, alors ce sera certainement pour des gens impliqués et qui peuvent justifier qu'ils ont écrit les messages bien mieux que par un token. En plus l'IP sera probablement toujours dans la base donc ça suffit largement à mon sens.

Je ne trouve pas que ta proposition soit une mauvaise idée, mais je pense que le besoin auquel ça répond est vraiment marginal.

En ce qui concerne les logs de service et de sécurité (anti-spam, autre), je pensais utiliser de manière globale au site un InfluxDB ou Logstash, ou solution qui permet de faire de la rotation automatiquement. Comme ça les logs techniques sont séparés de la BDD, et en cas de pépin on garde ceintures, bretelles et parachute.

+1. On refait pas une v42.

Par contre faut prévoir un truc pour lutter contre le spam (volontaire/manuel, donc un captcha suffira pas) et le contournement de blocage.

Limiter au niveau des IPs par exemple...

Ça t’a RGPD-ment pas le droit. Un utilisateur doit avoir un moyen d’accéder à ses données personnelles (et j’aurais tendance à dire qu’un pseudo + un message en est).

Tu borderlines sur l'impossible/le non-sens parce que le principe du post invité c'est de ne pas laisser de données personnelles (compte) derrière toi. Donc si tu prétends que le contenu d'un post invité est des données personnelles alors ce post invité est structurellement un échec.

> Mais est-ce que finalement c’est si utile que ça de stocker l’IP de chaque invité ayant posté un message ? Oui, non pas pour les identifier fonctionnellement sur le site, mais pour détecter les posts abusifs, les liers avec les IPs des membres inscrits, et traquer les trolls. C'est pas contraire au RGPD, et on peut les virer après 1 an si tu veux, ce qui m'intéresse c'est les informations dans l'immédiat. > Si un invité veut faire valoir ses droits sur ses précédents messages, il avait qu’à s’inscrire avant… il suffit de préciser qu’un invité ne peut pas éditer ou assigner son message à un futur compte et hop. Bien plus simple à gérer. Et plus logique. +1. Concis et suffisant. > Autre méthode : on créé le compte, si ça matche avec un invité, on invite l’utilisateur a entrer en contact avec l’équipe de modération pour récupérer ses contenus. L’action est manuelle, et on peut s’adapter aux situations bizarre (pseudo squatté, plusieurs tokens, etc.). Pour les rares cas où il est important de récupérer les données, je pense que c'est le bon plan. Mais comme une intervention manuelle est nécessaire, alors ce sera certainement pour des gens impliqués et qui peuvent justifier qu'ils ont écrit les messages bien mieux que par un token. En plus l'IP sera probablement toujours dans la base donc ça suffit largement à mon sens. Je ne trouve pas que ta proposition soit une mauvaise idée, mais je pense que le besoin auquel ça répond est vraiment marginal. > En ce qui concerne les logs de service et de sécurité (anti-spam, autre), je pensais utiliser de manière globale au site un InfluxDB ou Logstash, ou solution qui permet de faire de la rotation automatiquement. Comme ça les logs techniques sont séparés de la BDD, et en cas de pépin on garde ceintures, bretelles et parachute. +1. On refait pas une v42. > Par contre faut prévoir un truc pour lutter contre le spam (volontaire/manuel, donc un captcha suffira pas) et le contournement de blocage. Limiter au niveau des IPs par exemple... > Ça t’a RGPD-ment pas le droit. Un utilisateur doit avoir un moyen d’accéder à ses données personnelles (et j’aurais tendance à dire qu’un pseudo + un message en est). Tu borderlines sur l'impossible/le non-sens parce que le principe du post invité c'est de ne pas laisser de données personnelles (compte) derrière toi. Donc si tu prétends que le contenu d'un post invité est des données personnelles alors ce post invité est structurellement un échec.

Eragon commented

2020-01-29 22:28:16 +01:00

Member

Donc si tu prétends que le contenu d’un post invité est des données personnelles alors ce post invité est structurellement un échec.

+1

Oui, non pas pour les identifier fonctionnellement sur le site, mais pour détecter les posts abusifs, les liers avec les IPs des membres inscrits, et traquer les trolls. C’est pas contraire au RGPD, et on peut les virer après 1 an si tu veux, ce qui m’intéresse c’est les informations dans l’immédiat.

Du coup, mit en bdd dans une table spécifique ?

Par contre faut prévoir un truc pour lutter contre le spam (volontaire/manuel, donc un captcha suffira pas) et le contournement de blocage.

Limiter au niveau des IPs par exemple…

Je me demande si limiter au niveau de l'IP va pas causer des problèmes pour les posts légitimes rapides. Type post, et modification rapide du post.

> Donc si tu prétends que le contenu d’un post invité est des données personnelles alors ce post invité est structurellement un échec. +1 > Oui, non pas pour les identifier fonctionnellement sur le site, mais pour détecter les posts abusifs, les liers avec les IPs des membres inscrits, et traquer les trolls. C’est pas contraire au RGPD, et on peut les virer après 1 an si tu veux, ce qui m’intéresse c’est les informations dans l’immédiat. Du coup, mit en bdd dans une table spécifique ? > > Par contre faut prévoir un truc pour lutter contre le spam (volontaire/manuel, donc un captcha suffira pas) et le contournement de blocage. > Limiter au niveau des IPs par exemple… Je me demande si limiter au niveau de l'IP va pas causer des problèmes pour les posts légitimes rapides. Type post, et modification rapide du post.

Darks commented

2020-01-29 22:42:53 +01:00

Author

Owner

Bon, après relecture du RGPD, je vous propose cette interprétation :

Le post en tant qu'invité avec pseudo - email - message est correct car :

si l'email est renseigné, ce sont des données personnelles (rattachables à un individu unique), et via l'email on peut demander à faire appliquer ses droits
si l'email n'est pas renseigné, ce ne sont pas des données personnelles car non rattachables à une personne unique.

Ce que je propose

Faire un post invité hyper basique. Le message n'est alors pas une donnée personnelle, donc le RGPD ne s'applique pas (sur ce point ci en tout cas).

Deux écoles :

Pseudo + message
Message uniquement

Le cas 2 est assez drastique, mais a l'avantage d'être hyper safe d'un point de vue données personnelles.

Finalement recueillir l'email ne sert pas la finalité de base qui est « poster un contenu sans partager des données personnelles ». Donc je serais plutôt pour l'enlever.

Et bien entendu on prévient que le post en tant qu'invité, de par sa nature anonyme, ne permet pas l'édition ou la suppression à postériori.

Le plus de la fin

On peut imaginer un token JWT stocké dans un cookie/other qui permettrait à un visiteur d'éditer/supprimer ses messages tant que sa session est active. On a pas non plus de donnée personnelles dans ce cookie, donc là aussi on est bon.

Bon, après relecture du RGPD, je vous propose cette interprétation : Le post en tant qu'invité avec pseudo - email - message est correct car : - si l'email est renseigné, ce sont des données personnelles (rattachables à un individu unique), et via l'email on peut demander à faire appliquer ses droits - si l'email n'est pas renseigné, ce ne sont pas des données personnelles car non rattachables à une personne unique. ### Ce que je propose Faire un post invité hyper basique. Le message n'est alors pas une donnée personnelle, donc le RGPD ne s'applique pas (sur ce point ci en tout cas). Deux écoles : 1. Pseudo + message 2. Message uniquement Le cas 2 est assez drastique, mais a l'avantage d'être hyper safe d'un point de vue données personnelles. Finalement recueillir l'email ne sert pas la finalité de base qui est « poster un contenu sans partager des données personnelles ». Donc je serais plutôt pour l'enlever. Et bien entendu on prévient que le post en tant qu'invité, de par sa nature anonyme, ne permet pas l'édition ou la suppression à postériori. ### Le plus de la fin On peut imaginer un token JWT stocké dans un cookie/other qui permettrait à un visiteur d'éditer/supprimer ses messages tant que sa session est active. On a pas non plus de donnée personnelles dans ce cookie, donc là aussi on est bon.

👍 2

Breizh commented

2020-01-29 22:46:19 +01:00

Member

Ça me paraît correct. J'ai jamais lu le RGPD, personnellement, ni même de résumé, mais ça me paraît cohérent et acceptable.

Eragon commented

2020-01-29 22:47:02 +01:00

Member

Le cas deux avec "Le plus de la fin" me va bien.
Il à l'avantage, côté technique, de ne pas demander à créer un utilisateur spécifique, ou devoir lier un pseudo, pour chaque invité.
Ce qui permet, de ne pas réserver un pseudo pour un utilisateur qui s'inscrit

Le cas deux avec "Le plus de la fin" me va bien. Il à l'avantage, côté technique, de ne pas demander à créer un utilisateur spécifique, ou devoir lier un pseudo, pour chaque invité. Ce qui permet, de ne pas réserver un pseudo pour un utilisateur qui s'inscrit

Lephenixnoir commented

2020-01-29 22:50:58 +01:00

Owner

Ça me va aussi, je n'ai pas d'a priori sur le plus de la fin, qui est utile d'un côté mais confus de l'autre parce que la durée de la session n'est pas un truc dont on connaît vraiment la portée et les gens ne vont pas forcément comprendre pourquoi ils ne peuvent soudain plus éditer leurs messages. Faites comme vous préférez.

Reste pour moi la question de l'IP, où j'ai vu Darks dire "L'IP c'est un truc à part qui n'est pas spécifique au post invité" ; tant qu'elle est quelque part je n'ai rien à ajouter.

Ça me va aussi, je n'ai pas d'a priori sur le plus de la fin, qui est utile d'un côté mais confus de l'autre parce que la durée de la session n'est pas un truc dont on connaît vraiment la portée et les gens ne vont pas forcément comprendre pourquoi ils ne peuvent soudain plus éditer leurs messages. Faites comme vous préférez. Reste pour moi la question de l'IP, où j'ai vu Darks dire "L'IP c'est un truc à part qui n'est pas spécifique au post invité" ; tant qu'elle est quelque part je n'ai rien à ajouter.

Eragon commented

2020-01-29 23:07:53 +01:00

Member

Ça me va aussi, je n’ai pas d’a priori sur le plus de la fin, qui est utile d’un côté mais confus de l’autre parce que la durée de la session n’est pas un truc dont on connaît vraiment la portée et les gens ne vont pas forcément comprendre pourquoi ils ne peuvent soudain plus éditer leurs messages. Faites comme vous préférez.

Je propose de renouveler la durée de vie du cookie à chaque message posté, de manière à ce que l'édition d'un message précédemment posté soit simple tant que l'utilisateur reste actif, je pense à mettre une limite de temps d'un mois pour ce cookie, ça me semble largement assez.

> Ça me va aussi, je n’ai pas d’a priori sur le plus de la fin, qui est utile d’un côté mais confus de l’autre parce que la durée de la session n’est pas un truc dont on connaît vraiment la portée et les gens ne vont pas forcément comprendre pourquoi ils ne peuvent soudain plus éditer leurs messages. Faites comme vous préférez. Je propose de renouveler la durée de vie du cookie à chaque message posté, de manière à ce que l'édition d'un message précédemment posté soit simple tant que l'utilisateur reste actif, je pense à mettre une limite de temps d'un mois pour ce cookie, ça me semble largement assez.

Eragon commented

2020-01-29 23:12:19 +01:00

Member

class Guest(User):
    """ Unregistered user with minimal privileges """

    __tablename__ = 'guest'
    __mapper_args__ = {'polymorphic_identity': __tablename__}

    # ID of the [User] entry
    id = db.Column(db.Integer, db.ForeignKey('user.id'), primary_key=True)
    # Reusable username, can be the name of a member (will be distinguished at
    # rendering time)
    username = db.Column(db.Unicode(64), index=True)
    # IP address, 47 characters is the max for an IPv6 address
    ip = db.Column(db.String(47))

    def __repr__(self):
        return f'<Guest: {self.username} ({self.ip})>'

Hum... va falloir modifier cette class en fonction de ce qu'on choisi de faire ici.

```python class Guest(User): """ Unregistered user with minimal privileges """ __tablename__ = 'guest' __mapper_args__ = {'polymorphic_identity': __tablename__} # ID of the [User] entry id = db.Column(db.Integer, db.ForeignKey('user.id'), primary_key=True) # Reusable username, can be the name of a member (will be distinguished at # rendering time) username = db.Column(db.Unicode(64), index=True) # IP address, 47 characters is the max for an IPv6 address ip = db.Column(db.String(47)) def __repr__(self): return f'<Guest: {self.username} ({self.ip})>' ``` Hum... va falloir modifier cette class en fonction de ce qu'on choisi de faire ici.

Lephenixnoir commented

2020-01-29 23:18:07 +01:00

Owner

Je propose de renouveler la durée de vie du cookie à chaque message posté, de manière à ce que l’édition d’un message précédemment posté soit simple tant que l’utilisateur reste actif

Tu peux mais c'est juste encore plus confus qu'avant. ^^"

> Je propose de renouveler la durée de vie du cookie à chaque message posté, de manière à ce que l’édition d’un message précédemment posté soit simple tant que l’utilisateur reste actif Tu peux mais c'est juste encore plus confus qu'avant. ^^"

Eragon commented

2020-01-29 23:25:02 +01:00

Member

Un message d'avertissement peut régler ça.
En postant en tant qu'invité vous ne serez en mesure de supprimer ou d'éditer vos message uniquement durant les {app_guest_edit_delay} jours après votre dernière activité

Remarque l'utilisation d'activité me plait pas, tu aurais pas une autre formulation ?

Un message d'avertissement peut régler ça. `En postant en tant qu'invité vous ne serez en mesure de supprimer ou d'éditer vos message uniquement durant les {app_guest_edit_delay} jours après votre dernière activité` Remarque l'utilisation d'`activité` me plait pas, tu aurais pas une autre formulation ?

Breizh commented

2020-01-30 10:25:50 +01:00

Member

Autant le cookie pour un message à court terme (genre 15 minutes, si le mec a fait une faute ou quoi) ça va (en gros juste le temps que la personne a la page d'ouverte à peu près), autant du long terme non. Et encore moins avec un message, parce qu'il y a tellement de raisons pour que finalement le cookie ait disparu avant…

L'avantage du cookie court terme, c'est que qu'on peut faire un pseudo-blocage (merci d'attendre avant de poster, préférez éditer votre message). Ça évitera pas le spam de bots ou d'un type qui veut vraiment spammer par tous les moyens, mais ça éviterais le multi-post. Ça ou fusion automatique comme la v42 (mais sans avoir la notif de nouveau message comme la v42 dans ce cas).

Et honnêtement, c'pas trop grave si les invités ont des fonctionnalités limitées, je veux dire, c'est un forum, si tu veux vraiment y participer tu t'inscris… si on veut proposer le post invité à la base c'est juste pour que l'étape inscription ne rebute pas un nouveau venu, il me semble.

Autant le cookie pour un message à court terme (genre 15 minutes, si le mec a fait une faute ou quoi) ça va (en gros juste le temps que la personne a la page d'ouverte à peu près), autant du long terme non. Et encore moins avec un message, parce qu'il y a tellement de raisons pour que finalement le cookie ait disparu avant… L'avantage du cookie court terme, c'est que qu'on peut faire un pseudo-blocage (merci d'attendre avant de poster, préférez éditer votre message). Ça évitera pas le spam de bots ou d'un type qui veut vraiment spammer par tous les moyens, mais ça éviterais le multi-post. Ça ou fusion automatique comme la v42 (mais sans avoir la notif de nouveau message comme la v42 dans ce cas). Et honnêtement, c'pas trop grave si les invités ont des fonctionnalités limitées, je veux dire, c'est un forum, si tu veux vraiment y participer tu t'inscris… si on veut proposer le post invité à la base c'est juste pour que l'étape inscription ne rebute pas un nouveau venu, il me semble.

Eragon commented

2020-01-30 10:34:16 +01:00

Member

Ok, je comprend ton point de vue, et il me va. Il me semble même mieux que mon avis précédant.

Eragon commented

2020-01-31 13:05:34 +01:00

Member

Attention ! Vous semblez ne pas être connecté, votre message sera posté en mode Invité,
vous ne pourrez le modifier durant uniquement 10 minutes après l'avoir posté.
De plus pour éviter le spam vous êtes limité à un message toute les 30 secondes.

Ça vous semble bien comme message d'avertissement ?
Ça donne ça sans css, je trouve que c'est un peut long. Et je sait pas comment mettre en valeur le texte.

Je n'ai pas du tout implémenté quoi que ce soit.
De plus il semblerait que le fait que l'éditeur soit un widget m’empêche d'utiliser une variable, pourtant passé à tout les templates, current_user n'est pas vu par jinja lors de la génération de l'html.

``` Attention ! Vous semblez ne pas être connecté, votre message sera posté en mode Invité, vous ne pourrez le modifier durant uniquement 10 minutes après l'avoir posté. De plus pour éviter le spam vous êtes limité à un message toute les 30 secondes. ``` Ça vous semble bien comme message d'avertissement ? Ça donne ça sans css, je trouve que c'est un peut long. ![image](/attachments/a291050b-8fd1-4c2b-a794-a1e21bb9f8dc) Et je sait pas comment mettre en valeur le texte. Je n'ai pas du tout implémenté quoi que ce soit. De plus il semblerait que le fait que l'éditeur soit un widget m’empêche d'utiliser une variable, pourtant passé à tout les templates, `current_user` n'est pas vu par jinja lors de la génération de l'html.

image.png

29 KiB

Lephenixnoir commented

2020-02-02 22:15:43 +01:00

Owner

C'est pas mal ! Voilà une suggestion, tu en fais ce que tu veux.

Attention ! Vous n'êtes pas connecté(e). Si vous postez maintenant, votre message sera anonymisé dans 10 minutes et vous ne pourrez plus le modifier. Pour éviter cela, connectez-vous ou créez un compte.

Pour le mettre en valeur, je suggère une div orange type message flash. 😉

Pour le taux de spam, il suffit de le dire au cas où il est dépassé (en renvoyant la page avec une erreur et le formulaire rerempli proprement), ce que tu devras faire de toute façon.

C'est pas mal ! Voilà une suggestion, tu en fais ce que tu veux. > Attention ! Vous n'êtes pas connecté(e). Si vous postez maintenant, votre message sera anonymisé dans 10 minutes et vous ne pourrez plus le modifier. Pour éviter cela, [connectez-vous](http://#) ou [créez un compte](http://#). Pour le mettre en valeur, je suggère une div orange type message flash. :wink: Pour le taux de spam, il suffit de le dire au cas où il est dépassé (en renvoyant la page avec une erreur *et le formulaire rerempli proprement*), ce que tu devras faire de toute façon.

Darks commented

2020-02-05 13:46:55 +01:00

Author

Owner

Classe Guest

Par rapport à la classe Guest, à minima il faut dégager l'adresse IP (qui sera stockée ailleurs).

Et limite je me demande si en effet ça serait pas plus simple de rattacher les posts à un compte « Invité ». Ça permet de dégager la classe Guest, de virer la polymorphie sur User → Member, etc.

Édition temporaire

Concernant l'édition temporaire des messages, un truc qui peut être jouable est d'utiliser un JWT contenant l'ID du contenu pouvant être modifié. On stocke ce JWT dans le cookie de session de l'utilisateur.

Quand l'invité poste un message, on regarde le contenu du JWT. Si il est valide (y'a un système de signature pour être sûr), on regarde si l'ID du contenu pouvant être modifié est dedans. Si c'est le cas l'édition/suppression est autorisée, sinon on annule. On peut aussi coupler ça à une vérification de la date du post pour limiter l'édition à X minutes et non à la durée de la session utilisateur.

### Classe Guest Par rapport à la classe `Guest`, à minima il faut dégager l'adresse IP (qui sera stockée ailleurs). Et limite je me demande si en effet ça serait pas plus simple de rattacher les posts à un compte « Invité ». Ça permet de dégager la classe `Guest`, de virer la polymorphie sur `User → Member`, etc. ### Édition temporaire Concernant l'édition temporaire des messages, un truc qui peut être jouable est d'utiliser un JWT contenant l'ID du contenu pouvant être modifié. On stocke ce JWT dans le cookie de session de l'utilisateur. Quand l'invité poste un message, on regarde le contenu du JWT. Si il est valide (y'a un système de signature pour être sûr), on regarde si l'ID du contenu pouvant être modifié est dedans. Si c'est le cas l'édition/suppression est autorisée, sinon on annule. On peut aussi coupler ça à une vérification de la date du post pour limiter l'édition à X minutes et non à la durée de la session utilisateur.

Lephenixnoir commented

2020-02-05 17:53:14 +01:00

Owner

Et limite je me demande si en effet ça serait pas plus simple de rattacher les posts à un compte « Invité ».

Je suis pas chaud, ça va mettre pas mal de bordel. Il y aura plein d'IPs pour le même utilisateur, faudra exclure une unique personne de toutes les requêtes qui cherchent des membres (!!), et ça n'a pas de sens d'avoir (au hasard) des trophées pour les invités. Se débrouiller pour que les flashs/infos spécifiques aux membres n'apparaissent pas après un post invité va nous emmerder tellement dans tous les coins, j'ai vraiment pas envie d'essayer.

Ton système d'édition temporaire paraît pas mal.

> Et limite je me demande si en effet ça serait pas plus simple de rattacher les posts à un compte « Invité ». Je suis pas chaud, ça va mettre pas mal de bordel. Il y aura plein d'IPs pour le même utilisateur, faudra exclure une unique personne de toutes les requêtes qui cherchent des membres (!!), et ça n'a pas de sens d'avoir (au hasard) des trophées pour les invités. Se débrouiller pour que les flashs/infos spécifiques aux membres n'apparaissent pas après un post invité va nous emmerder tellement dans tous les coins, j'ai vraiment pas envie d'essayer. Ton système d'édition temporaire paraît pas mal.

Darks commented

2020-02-05 20:48:39 +01:00

Author

Owner

Ben non. Les IP sont pas stockées par utilisateur mais par post (entre autres pour prévenir l'usurpation de compte). Donc ça change rien.

Au niveau des trophées, avec le système de contexte, c'est pas compliqué de les ignorer. Et les flash/infos spécifiques, c'est pas parce qu'un invité poste sous le compte Invité qu'il est loggué en tant qu'Invité.

Pour l'édition de post, je vais tenter de faire un PoC ce WE.

Ben non. Les IP sont pas stockées par utilisateur mais par post (entre autres pour prévenir l'usurpation de compte). Donc ça change rien. Au niveau des trophées, avec le système de contexte, c'est pas compliqué de les ignorer. Et les flash/infos spécifiques, c'est pas parce qu'un invité poste sous le compte Invité qu'il est loggué en tant qu'Invité. Pour l'édition de post, je vais tenter de faire un PoC ce WE.

Lephenixnoir commented

2020-02-05 22:00:44 +01:00

Owner

Les IP sont pas stockées par utilisateur mais par post (entre autres pour prévenir l’usurpation de compte).

Certes, mais ça ne change pas le problème.

Au niveau des trophées, avec le système de contexte, c’est pas compliqué de les ignorer. Et les flash/infos spécifiques, c’est pas parce qu’un invité poste sous le compte Invité qu’il est loggué en tant qu’Invité.

Il s'agit pas que des trophées. Ton invité va avoir un nom. Il va sortir dans la liste des membres. On pourra lui envoyer des MPs. On pourra le citer sur le forum. Toutes ses limites seront pour tous les invités. Il aura une page de profil avec dessus tous les topics et tous les commentaires invités du site. Il aura un compteur de points. Tous ces machins n'ont aucun sens et je ne veux surtout pas qu'on ait à rajouter des exceptions pour faire rentrer ça dans le modèle Member.

Le modèle actuel convient très bien à ce qu'on veut même avec aucun attribut spécial dans la classe Guest, donc s'il te plaît ce n'est vraiment pas le truc à simplifier. Utilise User directement si tu veux mais pas dans l'autre sens.

> Les IP sont pas stockées par utilisateur mais par post (entre autres pour prévenir l’usurpation de compte). Certes, mais ça ne change pas le problème. > Au niveau des trophées, avec le système de contexte, c’est pas compliqué de les ignorer. Et les flash/infos spécifiques, c’est pas parce qu’un invité poste sous le compte Invité qu’il est loggué en tant qu’Invité. Il s'agit pas que des trophées. Ton invité va avoir un nom. Il va sortir dans la liste des membres. On pourra lui envoyer des MPs. On pourra le citer sur le forum. Toutes ses limites seront pour tous les invités. Il aura une page de profil avec dessus tous les topics et tous les commentaires invités du site. Il aura un compteur de points. Tous ces machins n'ont aucun sens et je ne veux surtout pas qu'on ait à rajouter des exceptions pour faire rentrer ça dans le modèle `Member`. Le modèle actuel convient très bien à ce qu'on veut même avec aucun attribut spécial dans la classe `Guest`, donc s'il te plaît ce n'est vraiment pas le truc à simplifier. Utilise `User` directement si tu veux mais pas dans l'autre sens.

Darks commented

2020-02-07 17:25:25 +01:00

Author

Owner

J'analyse un peu plus ce qu'on pourrait avoir avec une classe Guest ne contenant qu'un pseudo. Je te propose un usecase classique.

Un invité poste un message en tant que Darks. Le site lui dit « Le pseudo est déjà utilisé par un membre ».
Il reposte alors son message en tant que Toto. Ça passe.
Au cours du temps, plusieurs messages sont postés sous le nom de Toto en tant qu'invité.
Un membre souhaite créer un compte Toto.

Que fait-on ? J'ai identifié ces contraintes :

Par définition on ne peut pas légitimement attribuer les messages invités de <Guest Toto> à <Member Toto>
On ne peut pas non plus raisonnablement interdire l'utilisation de tous les pseudos utilisés par des Guest

Je vois quelques choix possibles :

On identifie clairement sous le nom du posteur son status. C'est déjà en partie implémenté en plus, pour les membres du moins.

Avantages : Facile à mettre en place, ça fait le taf.
Inconvénients : On se retrouve avec des posts Toto et Toto avec juste une légère indication sur l'origine.

Quand un membre prend un compte qui est utilisé par un invité, on remplace le pseudo de l'invité par Invité #ID

Avantages : La différence est forte entre l'invité et le membre (i.e. on ne peut pas faire inconsciemment un lien entre l'invité et le membre), on garde les fils de discussion cohérents.
Inconvients : plus lourd à mettre en place.

Z'en pensez quoi ?

J'analyse un peu plus ce qu'on pourrait avoir avec une classe `Guest` ne contenant qu'un pseudo. Je te propose un usecase classique. 1. Un invité poste un message en tant que `Darks`. Le site lui dit « Le pseudo est déjà utilisé par un membre ». 2. Il reposte alors son message en tant que `Toto`. Ça passe. 3. Au cours du temps, plusieurs messages sont postés sous le nom de `Toto` en tant qu'invité. 4. Un membre souhaite créer un compte `Toto`. Que fait-on ? J'ai identifié ces contraintes : - Par définition on ne peut pas légitimement attribuer les messages invités de `<Guest Toto>` à `<Member Toto>` - On ne peut pas non plus raisonnablement interdire l'utilisation de tous les pseudos utilisés par des `Guest` Je vois quelques choix possibles : 1. On identifie clairement sous le nom du posteur son status. C'est déjà en partie implémenté en plus, pour les membres du moins. - Avantages : Facile à mettre en place, ça fait le taf. - Inconvénients : On se retrouve avec des posts `Toto` et `Toto` avec juste une légère indication sur l'origine. 2. Quand un membre prend un compte qui est utilisé par un invité, on remplace le pseudo de l'invité par `Invité #ID` - Avantages : La différence est forte entre l'invité et le membre (i.e. on ne peut pas faire inconsciemment un lien entre l'invité et le membre), on garde les fils de discussion cohérents. - Inconvients : plus lourd à mettre en place. Z'en pensez quoi ?

Lephenixnoir commented

2020-02-07 17:37:32 +01:00

Owner

Merci. Je pense que la solution 1 peut suffire, notamment si tu es un peu plus explicite, par exemple en mettant des guillemets. Invité "Toto". Ça contrasterait avec le Toto des membres, qui est un lien, et en couleur. Quitte à mettre Invité en gras je pense que la distinction est suffisament forte.

Pour la solution 2, je n'ai pas d'a priori, par contre je note que quand tu dis "on garde les fils de discussion cohérents", tu oublies peut-être qu'on se réfère souvent aux invités par leur nom, et du coup le sujet peut devenir un peu confus. (Parce que si tu mets un numéro c'est qu'un membre a maintenant le nom et du coup on va avoir à fond l'impression qu'on se réfère au membre.)

Note que dans le cas où la solution 1 est adoptée, on peut poster en invité avec n'importe quel pseudo, y compris si un membre existe déjà. Et j'appuie le fait qu'en effet, on ne peut pas réattribuer les messages invités.

Merci. Je pense que la solution 1 peut suffire, notamment si tu es un peu plus explicite, par exemple en mettant des guillemets. *Invité "Toto"*. Ça contrasterait avec le *[Toto](http://#)* des membres, qui est un lien, et en couleur. Quitte à mettre *Invité* en gras je pense que la distinction est suffisament forte. Pour la solution 2, je n'ai pas d'a priori, par contre je note que quand tu dis *"on garde les fils de discussion cohérents"*, tu oublies peut-être qu'on se réfère souvent aux invités par leur nom, et du coup le sujet peut devenir un peu confus. (Parce que si tu mets un numéro c'est qu'un membre a maintenant le nom et du coup on va avoir à fond l'impression qu'on se réfère au membre.) Note que dans le cas où la solution 1 est adoptée, on peut poster en invité avec n'importe quel pseudo, y compris si un membre existe déjà. Et j'appuie le fait qu'en effet, on ne peut pas réattribuer les messages invités.

Eragon commented

2020-02-08 16:22:26 +01:00

Member

Va pour la solution 1

Eragon commented

2020-02-23 13:01:03 +01:00

Member

Une autre idée est de préfixer les comptes Guest pat Invité : et interdire aux gens de prendre un compte commençant par Invité : Ça me semble simple, et clair. Sans pour autant bloquer le choix de pseudo à l’inscription.(personne ne veux d'un compte préfixé de Invité : )

Une autre idée est de préfixer les comptes Guest pat `Invité : ` et interdire aux gens de prendre un compte commençant par `Invité : ` Ça me semble simple, et clair. Sans pour autant bloquer le choix de pseudo à l’inscription.(personne ne veux d'un compte préfixé de `Invité : `)

Lephenixnoir commented

2020-02-23 14:24:20 +01:00

Owner

Ça revient à ma solution avec un autre préfixe si j'ai bien compris ? (Juste pour être sûr !)

En tous cas ça me va bien aussi, de toute façon on ne peut pas avoir un compte dont le nom commence par "Invité :" parce que les espaces et deux points ne sont pas autorisés.

Ça revient à ma solution avec un autre préfixe si j'ai bien compris ? (Juste pour être sûr !) En tous cas ça me va bien aussi, de toute façon on ne peut pas avoir un compte dont le nom commence par "Invité :" parce que les espaces et deux points ne sont pas autorisés.

Darks referenced this issue from a commit

2020-07-18 07:53:28 +02:00

feat(forum): ajout du post invité sur les topics (#36) - Encore une fois, penser à faire ces ACL… (#40)

Darks referenced this issue

2020-07-18 07:55:54 +02:00

feat: ajout du post en tant qu'invité (#36) #52

Darks closed this issue

2020-07-18 07:56:14 +02:00

Darks referenced this issue from a commit

2020-07-19 20:44:37 +02:00

Merge pull request 'feat: ajout du post en tant qu'invité (#36)' (#52) from dev into preprod

Le post en tant qu'invité plante lamentablement #36

Ce que je propose

Le plus de la fin

Classe Guest

Édition temporaire