Protection plus stricte des posts invités ? #99

Closed
opened 1 year ago by Lephenixnoir · 3 comments
Owner

Je propose de modifier un peu la façon dont on prévoit de traiter les posts invités, sur deux points :

  • Ne pas permettre leur édition.
  • Ne pas permettre leur récupération par un compte.

La première proposition est motivée par la difficulté de vérifier l'identité du client qui modifie. On n'oublie pas qu'il y a des IP publiques partagées par des grands groupes d'utilisateur, surtout dans les écoles, donc valider par là n'est pas suffisant.

De plus, il y a déjà un concept qui concrétise l'identité d'un utilisateur, et c'est celui de compte membre. Ça me paraît un peu casse-pieds, et en plus un peu superflu, de vouloir programmer pour les invités une reconnaissance d'identité qui est déjà faite en mieux par les comptes.

Autoriser la modification dans une période limitée c'est pas délirant mais c'est pas non plus très utile, pour les typos il y a déjà des correcteurs orthographiques.


La seconde proposition est motivée par un problème de privilèges. Si on peut récupérer les messages en créant un compte du même nom (comme actuellement sur la v43), alors n'importe qui peut créer un compte, capturer le message, et supprimer le compte avec ses contenus immédiatement.

Plus spécifiquement cela donne à n'importe qui les droits de modération sur les messages invités.

Ce problème pourrait être mitigé par une vérification de l'identité du posteur lors de la création du compte, mais ça ne marche pas si plusieurs invités postent avec le même nom (ce qu'on ne teste pas) et de toute façon je pense là aussi que retrouver l'identité des invités a posteriori n'est pas productif.

Je propose de modifier un peu la façon dont on prévoit de traiter les posts invités, sur deux points : * Ne pas permettre leur édition. * Ne pas permettre leur récupération par un compte. --- La première proposition est motivée par la difficulté de vérifier l'identité du client qui modifie. On n'oublie pas qu'il y a des IP publiques partagées par des grands groupes d'utilisateur, surtout dans les écoles, donc valider par là n'est pas suffisant. De plus, il y a déjà un concept qui concrétise l'identité d'un utilisateur, et c'est celui de compte membre. Ça me paraît un peu casse-pieds, et en plus un peu superflu, de vouloir programmer pour les invités une reconnaissance d'identité qui est déjà faite en mieux par les comptes. Autoriser la modification dans une période limitée c'est pas délirant mais c'est pas non plus très utile, pour les typos il y a déjà des correcteurs orthographiques. --- La seconde proposition est motivée par un problème de privilèges. Si on peut récupérer les messages en créant un compte du même nom (comme actuellement sur la v43), alors n'importe qui peut créer un compte, capturer le message, et supprimer le compte avec ses contenus immédiatement. Plus spécifiquement cela donne à n'importe qui les droits de modération sur les messages invités. Ce problème pourrait être mitigé par une vérification de l'identité du posteur lors de la création du compte, mais ça ne marche pas si plusieurs invités postent avec le même nom (ce qu'on ne teste pas) et de toute façon je pense là aussi que retrouver l'identité des invités a posteriori n'est pas productif.
Lephenixnoir added the
proposal
label 1 year ago
Owner

À part enterrer définitivement l'idée de faire un système de cookie sur 15 minutes pour autoriser l'édition d'un message invité, y'a quoi qui change ? x)

Il me semble qu'on était déjà d'accord sur le second point, bah… j'approuve à nouveau.

Pour le premier, c'est le comportement par défaut auquel je m'attendais. Toutefois si un jour on veut appliquer le coup des 15 minutes pour éditer, je trouve ça pratique. Ça peut éviter les multi-posts parce que t'as oublié d'ajouter du contexte, un screenshot ou trois lignes de log. Et d'un point de vue modération ça change pas grand chose, parce que même si on a du spam à retardement, 15 minutes ne sont pas suffisantes pour passer au travers des mailles du filet.

À part enterrer définitivement l'idée de faire un système de cookie sur 15 minutes pour autoriser l'édition d'un message invité, y'a quoi qui change ? x) Il me semble qu'on était déjà d'accord sur le second point, bah… j'approuve à nouveau. Pour le premier, c'est le comportement par défaut auquel je m'attendais. Toutefois si un jour on veut appliquer le coup des 15 minutes pour éditer, je trouve ça pratique. Ça peut éviter les multi-posts parce que t'as oublié d'ajouter du contexte, un screenshot ou trois lignes de log. Et d'un point de vue modération ça change pas grand chose, parce que même si on a du spam à retardement, 15 minutes ne sont pas suffisantes pour passer au travers des mailles du filet.
Poster
Owner

Y'a pas forcément grand-chose qui change, je demandais surtout pour vérifier que y'a pas de désaccord (et aussi parce que j'avais un peu oublié la position «officielle» s'il y en avait une).

Le problème qui me gênait en termes de permissions c'est surtout le second, je ne crois pas qu'on en avait parlé. Bien reçu ici.

Vu le peu de double-posts invités je suis pas sûr de l'utilité du coup du cookie, mais ok si tu veux l'ajouter plus tard. J'ai vu beaucoup de commentaires en vrac, je voulais justement y mettre un peu d'ordre.

Y'a pas forcément grand-chose qui change, je demandais surtout pour vérifier que y'a pas de désaccord (et aussi parce que j'avais un peu oublié la position «officielle» s'il y en avait une). Le problème qui me gênait en termes de permissions c'est surtout le second, je ne crois pas qu'on en avait parlé. Bien reçu ici. Vu le peu de double-posts invités je suis pas sûr de l'utilité du coup du cookie, mais ok si tu veux l'ajouter plus tard. J'ai vu beaucoup de commentaires en vrac, je voulais justement y mettre un peu d'ordre.
Owner

Vu que la proposition correspond déjà au comportement actuel, je ferme le ticket.

Vu que la proposition correspond déjà au comportement actuel, je ferme le ticket.
Darks closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: devs/PCv5#99
Loading…
There is no content yet.