Bonjour tout le monde

Je ne sais pas trop qui se charge du site FreePON en lui-même actuellement (toujours underground78 ?), mais il serait bon d'en revoir un peu le code 😅
Le site est en effet très lent à s'afficher (14 secondes dans mon cas), non pas à cause de la connexion ou du PC du visiteur ou de la charge du serveur, mais à cause d'une grosse erreur qui partait pourtant d'une bonne et jolie idée : TOUTES les entrées sont chargées (12.490 à l'heure où je parle) puis sont ensuite triées grâce à un script datatables.
Au début du site, il n'y avait pas énormément de lignes à afficher donc ça ne se voyait pas, mais maintenant, c'est un peu horrible (niveau optimisation, ça reste joli sinon) et ne va pas aller en s'arrangeant.

Environ 4 secondes également ipv4 ; un peu plus long en v6 environ 6 sec.

C'est sympa cette idée de géoloc diy façon OSM, mais maintenant on a un problème : il ne faut pas que ça soit trop précis à cause des sabotages de la cinquième colonne des prorusses.
Je me souviens même que cette problématique m'avait été opposée lorsque j'avais voulu soumettre une mise à jour d'un NRA du temps de l'ADSL, mais je sais plus par qui (Ariase, DegroupTest, ou un site de bénévole... )
Les infrastructures critiques doivent être protégées. Est-ce qu'on a besoin d'une haute précision de géolocalisation pour les NRO ? Même pour les NRA ça n'était pas requis car les distances NRA<->Abonné ne sont jamais à vol d'oiseau.

La sécurité par le secret, ça ne fonctionne pas.

C'est une généralité théorique, mais c'est pas toujours vrai, loin de là. La preuve quand on base sa sécu sur une paire clé privée/publique, on ne partage pas la clé privée : on la garde secrète (soigneusement !)

C'est une généralité théorique, mais c'est pas toujours vrai, loin de là. La preuve quand on base sa sécu sur une paire clé privée/publique, on ne partage pas la clé privée : on la garde secrète (soigneusement !)

La sécurité des infrastructures par l'obscurité, ça ne fonctionne pas.

Le site est en effet très lent à s'afficher (14 secondes dans mon cas), non pas à cause de la connexion ou du PC du visiteur ou de la charge du serveur, mais à cause d'une grosse erreur qui partait pourtant d'une bonne et jolie idée : TOUTES les entrées sont chargées (12.490 à l'heure où je parle) puis sont ensuite triées grâce à un script datatables.

Je suis pas loin d'avoir une implémentation dynamique où tout est géré côté serveur mais j'ai un peu un dilemme...

Quand on lit la doc de DataTables on voit qu'ils recommandent de privilégier un chargement complet des données en dessous de 10k entrées et une gestion côté serveur au-dessus de 100k, entre les deux étant une zone grise. En pratique, le chargement est bien plus rapide avec la version côté serveur mais toutes les opérations de tri, recherche et cie sont bien sensiblement plus lentes car on paie la latence de la requête alors que le navigateur n'a aucun problème pour gérer cette quantité d'entrées (pour l'instant).