nud a écrit 898 commentaires

• 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.

S'il y a une page profil accessible en cliquant sur le nom de l'utilisateur, j'imagine que le popover (et son absence quand il n'y a pas de JS) tombe sur le coup de l'amélioration progressive.

Concernant Signal, c'est juste un peu d'anticipation de ma part sur le fait qu'ils veulent permettre un enregistrement sans numéro de téléphone, donc avec des usernames classiques. Mais bon, je suis sûr qu'on peut trouver 12 autres exemples de "usernames" que les utilisateurs pourraient désirer mettre en avant.

Peut être devrait-on quand même vérifier le nombre d'accès aux liens qui commencent par "https://linuxfr.org/users/" ?

Ou bien mettre en cache, je ne pense pas qu'il y ait tant de chose que ça qui change d'une visite à l'autre (à part peut-être le nombre de pertinentages)

Ajouter un lien vers le "compte Mastodon" après le nom d'utilisateur sur chacun de ses contenus (comme on a déjà (site Web personnel, adresse XMPP)), je trouverai ça coule pour découvrir des comptes Mastodon

J'ai fait exprès de ne pas inclure un tel lien en me disant que ça nécessitait un peu plue de réflexion, car inévitablement quelqu'un va demander qu'on ajoute Matrix, Signal, etc. le temps venu.

Il serait peut-être temps de réfléchir à une "vraie" page profil ou au moins à un popover avec tous les liens?

la validation d'un compte Linuxfr.org repose sur un courriel valide. Est-ce un souci pour servir ensuite de référence pour un compte Mastodon ?

Je ne suis pas sûr de comprendre la question mais la validation repose sur le fait que la personne contrôle les deux URLs. Même si un admin par exemple modifie le lien mastodon de quelqu'un il ne pourra pas le valider "côté mastodon" sauf si l'admin a aussi la main sur l'instance mastodon.

D'ailleurs on pourrait utiliser le même système pour valider une identité linuxfr si on voulait.

si le compte (ou l'instance) Mastodon est fermé/détruit, alors on pointera nulle part, faut-il détecter/gérer des pénibles du SEO/parking ?

LinuxFR fait ça pour XMPP ou pour les sites web?

mettre à jour l'image du schéma sql

J'ai testé la mise à jour depuis la version précédente et la création de la base de données from scratch, mais je ne sais pas si c'est de ça que tu parles.

https://github.com/linuxfrorg/linuxfr.org/pull/352

La documentation sus-mentionnée indique qu'un élement <link> convient également, ce qui aurait l'avantage de ne pas nécessiter de modification de l'interface utilisateur (pas de lien visible additionnel) hormis un petit champ additionnel en dessous de "Adresse XMPP xmpp:" (dont soit dit en passant le formattage est plutôt surprenant).

J'avais bien ce petit journal qui touchait le sujet mais il n'est plus de prime jeunesse.

En tant que dev d'application, il y avait aussi pas mal de comportements chelous à prendre en compte "pour raisons historiques", des hints à définir que plus personne n'utilise, le plein écran qui ne fonctionne correctement que si tu fais tourner ta chaise dans le bon sens, etc.

Je me souviens avoir eu ma dose de bugs rentrés parce que tel ou tel truc ne fonctionnait pas dans tel window manager parce que il part du principe que tel ou tel truc est fait.

Wayland était supposé remettre tout ça à plat en se basant sur les pratiques modernes.

XWayland a aussi sa dose de limitations vu que certaines choses permises par X11 ne le sont pas par Wayland (comme par exemple le positionnement arbitraire d'une fenêtre, qui pour le coup était un emmerdement majeur sous X11)

Le fax a à peine disparût

Si seulement, on a encore déployé un système de fax2mail cette semaine… Il y a toujours une valeur légale (imaginée ou réelle, je sais pas, IANAL) et des millions de pages de procédures qui font que le fax est toujours présent à beaucoup d'endroits, même si les systèmes de voip, fax2mail, mail2fax et consorts ont enterré la notion de l'accusé de réception d'un fax.

Ça me fait toujours rigoler d'imaginer que le fax est une façon de passer des données numériques sur un canal analogique, qui est maintenant émulé (attention aux codecs avec perte de qualité!) sur un canal numérique paquétisé.