nud a écrit 906 commentaires

Par rapport au problème posé, je suppose que le plus simple serait d'ajouter un last_seen_at qui serait mis à jour à chaque page vue.

Comme en vrai ça ne sert à rien de mettre à jour à chaque page vue je propose de le faire avec une granularité qui serait par exemple une journée, càd un champ de type "date" plutôt que "datetime". Comme ça pas besoin de le mettre à jour sans arrêt, ça minimise les UPDATE. Une semaine ou un an ça peut aussi convenir.

Tracker le "last seen" permet aussi de ne pas supprimer les comptes des gens qui commentent/moinssent peu. Et c'est plus facile à faire.

Oui ça n'a pas l'air très fiable, je vois que c'est affiché dans la box dans la colonne de gauche (app/views/users/_recent.html.haml):

      %li Dernière connexion : #{a.current_sign_in_at ? l(@user.account.current_sign_in_at) : "-"}
      %li Dernière action : #{a.updated_at ? l(@user.account.updated_at) : "-"}

Pour moi ça affiche "Dernière action : 13 février 2023 01:00:44" alors que j'ai apparemment posté pas mal de commentaires depuis!

Non, ce n'est pas uniquement la dernière « connexion ».

Donc dernière visite en étant identifié, mais la date de dernière visite n'est apparemment enregistrée nulle part. On a juste current_sign_in_at, last_sign_in_at (données personnelles également?) et updated_at (dans les tables accounts et users)

Quelle est la différence entre l'IP de la dernière connexion et l'IP courante ? J'imagine que ça se joue dans la définition que l'on donne à "connexion" ?

Il me semble, sans être juriste moi-même, que les historiques du serveur web sont également des données personnelles collectées par le site et que la durée de conservation est arbitraire. Si une conservation courte est justifiable pour raisons techniques, ça me semble un peu léger pour une conservation de un an.

La principale différence concerne la conservation de l’adresse de courriel pour permettre une réouverture du compte et un envoi de nouveau mot de passe en cas de demande

Oui, pendant un an (vu que l'adresse e-mail des comptes fermés est supprimée après un an si j'ai bien compris), mais il faut arriver au bon moment. Ou bien est-ce que la "fermeture" d'un compte inactif ne fait pas entrer le compte dans la catégorie des comptes "fermés par les personnes détentrices des comptes ou par l’équipe", et dès lors il ne serait pas supprimé après un an ?

Et au final, c'est à la personne qui a fermé son compte ou laissé son compte expiré de montrer qu'elle est bien cette personne…

C'est la teneur de ma question. Je ne vois pas vraiment comment quelqu'un peut prouver qu'iel est la personne derrière le compte expiré dans la mesure où la seule donnée identifiante est l'adresse e-mail dans le profil.

D'ailleurs dans quelle mesure une vieille moule détentrice d'un ou plusieurs comptes supprimés/expirés pourrait-elle demander l'association des anciens articles et commentaires à son dernier compte en date ?

Les comptes inactifs pendant trois ans seront fermés

1. Quelle est la définition formelle d'une "activité" sur le compte? Est-ce uniquement relatif à la date de dernière connexion ?
2. Est-ce qu'un e-mail de rappel sera envoyé aux détenteurs desdits comptes suffisamment à l'avance pour qu'ils aient la possiblité de réactiver ledit compte ?
3. Si un utilisateur revient après la fermeture d'un compte a-t-il la possibilité de le ré-ouvrir (vu que dans ce cas l'adresse e-mail est conservée pendant un an supplémentaire si je comprends bien) ?

Les comptes fermés […] depuis plus d’un an […] seront supprimées de la base active l’adresse de courriel

Est-ce que cela ne compromet pas la possibilité pour la personne concernée de prouver son identité pour demander par la suite par exemple de supprimer tous ses contenus ?

• adresse IP de création du compte : non modifiable par la suite ;
• adresse IP de dernière connexion.

Quelle est la finalité de ces deux informations ?

Dans le schéma de la base de donnée je ne trouve que les champs current_sign_in_ip et last_sign_in_ip. Ces champs sont utilisés par le gem devise, mais il ne me semble pas que ça inclut l'IP de création du compte.

Par ailleurs les IPs sont vraisemblablement également stockées dans les logs du serveur web (par défaut pendant 15 jours dans Debian Stretch si je ne m'abuse)

Le fait qu'il soit en Russie ne va pas aider à son financement. Et il ne peut pas quitter la Russie tant qu'il n'a pas payé sa transaction. Il est dans une situation de catch-22.

- a
    - b
        - c
            - d
                - e
                    - f
                        - g
                            - h

• a
  • b
    • c
      • d
        • e

…Autre bug

Je pense que, si tu veux éviter dans le futur la maltraitance des brachycères par les membres du site, l'approche la plus simple est celle qu'a justement prise Mastodon: permettre aux gens d'entrer jusqu'à 4 éléments affichés en tant que tableau sur leur profil.

Ces 4 éléments (ou plus si affinité) peuvent ensuite être reconnus comme des adresses HTTP ou XMPP ou n'importe quoi, et d'un coup tu te débarrasses du problème "site perso" vs "XMPP" vs "Mastodon" vs "Matrix" vs n'importe quoi: les gens peuvent mettre le lien ou le texte qu'ils veulent avec le libellé qu'ils veulent. Une migration peut facilement créer les nouveaux champs à partir des anciens. Par contre ça rend beaucoup plus difficile les statistiques mais a priori ça on s'en fout un peu non ?

Tu peux ensuite rajouter un rel="me" pour tous les liens HTTP(S) je suppose. L'implémentation actuelle du champ "mastodon" est suffisamment générique pour que le changement ne soit pas trop lourd.

"Historiquement" le champ mastodon était prévu pour uniquement la validation de compte mastodon, le lien n'était censé apparaître nulle part.

Adrien a suggéré de l'ajouter près du nick mais j'étais personnellement plutôt contre car maintenant on peut suggérer d'ajouter un lien twitter, matrix, peertube, pixelfed ou n'importe quoi d'autre. Il me semblerait plus adéquat d'introduire une vraie page de profil.

Mais effectivement, vu que le lien est visible il serait pertinent d'afficher un meilleur nom que l'implémentation la plus populaire actuellement, bien que tout le monde semble dire "sur Mastodon". Fediverse, ActivityPub? Quid d'autres projets comme PeerTube ou Pixelfed qui pourraient être considérés séparément comme on considère Instagram séparément de Twitter? Le problème c'est que la ligne est encore très floue.

L'idée de mettre plusieurs URLs est bien mais c'est pareil, il y a probablement assez de liens à côté du nick des gens, il faudrait les mettre sur une page de profil ou un popover à mon avis.

Et puis, écrivez des entrées de suivi ;-)

Il n'y a pas de href dans ton <a>.

La donnée "pseudoaléatoire" est un hash qui vient a priori de la conversion Markdown->HTML de linuxfr.

Dans le repository "html-pipeline-linuxfr", fichier lib/html/pipeline/svgtex.rb, le "code" est remplacé par un hash SHA1, qui est en principe remplacé par le code après traitement de mathjax. J'imagine qu'on est ici dans un cas particulier quelconque qui fait que le remplacement ne se fait pas.

À vue de nez et sans connaître le Ruby plus que ça, je dirais que un \0 dans la chaîne de remplacement dans le code ci-dessous (les gsub!) est remplacé par ce qui est capturé par la regex. C'est un comportement classique dans les autres langages et ça expliquerait le "bug" vu que ce qui est capturé, ben c'est le hash.

         def reinsert_code!
          @inline.each do |id, code|
            @text.gsub!(id) { "`#{code}`" }
          end
          @codemap.each do |id, spec|
            @text.gsub!(id) { "```#{spec[:lang]}\n#{spec[:code]}\n```" }
          end
        end

http://ncf.idallen.com/english.html :-)

Je propose de d'abord merger les deux PR qui utilisent le validateur http_url avant de changer le nom.

Non, le premier "croisillon" correspond bien au séparateur du fragment et est géré comme tel par matrix.to. Ils justifient même cette entorse au RFC par le fait que le fragment n'est pas envoyé au serveur.

Voir aussi ce bug report pour matrix.to: Switch to valid URL syntax #17

Correctif pour l'incohérence de validation: Fix validating the URL of user home sites #355

Faut pas laisser >trim dormir.

Non, allow_blank permet juste d'accepter une valeur vide, ce n'est pas passé à URI::regexp. Ça valide juste parce que la regexp n'est pas ancrée. Tu peux mettre n'importe quoi et ça passe, tant que y'a une URL quelque part.

irb(main):010:0> URI.regexp(%w(http https)).match?("https://matrix.to/#/#copie-publique:codelutin.com")
=> true
irb(main):011:0> URI.regexp(%w(http https)).match?("ziguigui+https://matrix.to/#/#copie-publique:codelutin.com")
=> true

C'est un bug qui mériterait d'être corrigé.

Par contre il est intéressant de constater que la RFC 3986 n'autorise pas de # dans le fragment (ce qui implique que l'URL de l'OP est invalide):

   segment       = *pchar
   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
   pct-encoded   = "%" HEXDIG HEXDIG
   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

La regexp retournée par URI.regexp est d'ailleurs correcte en ce sens:

(?:\#((?:[\-_.!~*'()a-zA-Z\d;\/?:@&=+$,\[\]]|%[a-fA-F\d]{2})*))?                  (?# 9: fragment)

Pour rendre l'URL valide au sens de la RFC 3986 il faudrait donc encoder le #:

irb(main):003:0> u = URI.parse("https://matrix.to/#/%23copie-publique:codelutin.com")
=> #<URI::HTTPS https://matrix.to/#/%23copie-publique:codelutin.com>

Par ailleurs, python accepte l'URL telle quelle, avec les 2 # (j'imagine que c'est une déviation de la RFC qui est assez courante et elle ne cause pas d'ambiguité en soi):

>>> urllib.parse.urlparse("https://matrix.to/#/#copie-publique:codelutin.com")
ParseResult(scheme='https', netloc='matrix.to', path='/', params='', query='', fragment='/#copie-publique:codelutin.com')

Les liens dans les dépèches et dans les bookmarks sont validés comme suit et refuse l'URL matrix.to:

validates :url, http_url: { protocols: PROTOCOLS, message: "L'adresse n'est pas valide" },

Le site web personnel de l'utilisateur est validé comme suit et accepte l'URL matrix.to:

validates_format_of :homesite, message: "L’adresse du site Web personnel n’est pas valide", with: URI::regexp(%w(http https)), allow_blank: true

Les bookmarks utilisent le même procédé pour indiquer que l'URL est mauvaise si la validation échoue:

flash.now[:alert] = "Votre lien semble invalide. Le confimez‑vous ?" unless @bookmark.link =~ /\A#{URI::regexp(['http', 'https'])}\z/

Ça vaudrait peut-être la peine d'uniformiser tout ça. :-)

A priori ce http_url vient de app/validators/http_url_validator.rb, qui utilise URI.parse mais échoue:

irb(main):001:0> URI.parse("https://matrix.to/#/#copie-publique:codelutin.com")
URI::InvalidURIError: bad URI(is not URI?): https://matrix.to/#/#copie-publique:codelutin.com
    from /usr/lib/ruby/2.3.0/uri/rfc3986_parser.rb:67:in `split'
    from /usr/lib/ruby/2.3.0/uri/rfc3986_parser.rb:73:in `parse'
    from /usr/lib/ruby/2.3.0/uri/common.rb:227:in `parse'
    from (irb):1
    from /usr/bin/irb:11:in `<main>'

Donc ruby n'est pas capable de parser une URI que sa regexp considère comme valide…

Bon je n'étais pas loin, le problème c'est que la validation des liens considère que l'URL "https://matrix.to/#/#copie-publique:codelutin.com" n'est pas valide car elle contient deux fois le caractère #.

J'imagine que le problème c'est le '#' ?

Après, en y regardant de plus près, dans le commit lié ci-dessus il s'agit d'enlever protocole et domaine, donc c'est toujours valide. Si le browser ne supporte pas de tels liens il faut corriger le bug dans le browser.

Des commits plus pertinents sont:

• 16adf9a5aee76e7a6f0c3c0a3e79ae6502149b21 Accept protocol-relative links to linuxfr.org in news links
• 193f3b348302cc8b48a83fcce40ac606f63c2049 Use protocol relative in 400.html
• 0c7d9ca660a674ead78908e4fb57af13dcb24cc9 Accept protocol-relative URL
• c2648f6cef078b583da58077275e28fe27c6681d Use protocol-relative URL for the image in wiki help
• 551918514f3b7fd365cc54db1a57e5a8db9ac875 Default avatar URL should be protocol-relative

Mais l'analyse reste juste. Ces URLs sont utilisées pour e.g. intégrer des images et intégrer une image en HTTP posait problème quand on voyait le site en HTTPS. Dans la mesure où DLFP utilise maintenant HTTPS partout, ça ne sert à rien de les conserver. C'est aussi la décision qu'a prise Wikipedia apparemment: mettre à jour les liens sans URL pour inclure https://.

Comme les commits ci-dessus impliquent surtout que DLFP a accepté les URLs sans scheme dans les contenus, il faudra soit modifier les contenus existants soit silencieusement ajouter le préfixe https://.

Ceci dit, AMHA le bug est avec le browser s'il casse la compatibilité ascendante de la sorte…

Quand LinuxFR est passé aux liens sans protocole, c'était parce que le site était servi en HTTP et en HTTPS, et les liens internes étaient un joyeux mélange. C'était en 2012.

Comme en 2023 on utilise HTTPS partout, peut-être que tout ça ne sert plus à rien et qu'on pourrait juste mettre des https:// partout. La seule question est relative à l'environnement de développement.