Aller au contenu
Les Forums d'Infoclimat

Ce tchat, hébergé sur une plateforme indépendante d'Infoclimat, est géré et modéré par une équipe autonome, sans lien avec l'Association.
Un compte séparé du site et du forum d'Infoclimat est nécessaire pour s'y connecter.

Fred59_

Conseil d'Administration
  • Compteur de contenus

    5 063
  • Inscription

  • Dernière visite

Tout ce qui a été posté par Fred59_

  1. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    C'est corrigé pour Luxembourg. Pour Metz, il manque en effet des données à cette période, je ne peux rien faire.
  2. Bonjour, Non, ce n'est pas possible pour le moment.
  3. Bonjour, Comme chaque année, Infoclimat édite ses calendriers photo, dans un format proche A3 et papier photo d'excellente qualité. 100 exemplaires sont mis en vente jusque début décembre. 19€ frais de ports compris en France métropolitaine, 17€ pour les adhérents. Plus d'infos : https://www.infoclimat.fr/boutique/details.php?id=8
  4. Fred59_

    36ème rencontre nationale Infoclimat en Haute-Loire

    c'est préférable oui, pour éviter de se retrouver dans un gîte vide si une activité est prévue
  5. Fred59_

    Bugs sur Infoclimat #2

    Sûr de nombreuses stations, les chiffres se rapprochaient mieux des valeurs de stations MF proches. Le problème c'est que le capteur d'une VP2 mesure le rayonnement diffus également. On ne pourra jamais déterminer l'ensoleillement comme le fait une station MF, car la station ne mesure pas suffisamment de paramètres pour le faire... Donc cette valeur restera toujours approximative quoi qu'on fasse. A mon avis elle est tout aussi fausse avant qu'après le filtre, le but est de donner un indicateur relatif a la station, qui se rapproche des normes de mesure MF, mais au vu de la structure du capteur c'est idiot de ne considérer que la valeur absolue sans le contexte de mesure qui est très différent d'une station pro... Plus d'infos : https://library.wmo.int/doc_num.php?explnum_id=3154 Historiquement, le seuil des 120W/m² de radiation directe (direct irradiance dans le texte) était déterminé comme seuil d'ensoleillement. Mais il s'agit ici du rayonnement mesuré avec le soleil face au capteur. Or, le capteur d'une VP2 est un capteur de radiation globale. Donc, on compare des torchons avec des serviettes, et quel que soit l'algorithme il sera très difficile de comparer les mesures.
  6. Il y a un topic sur les bugs, mais pas de topic sur les améliorations que l'on apporte régulièrement, je ne savais pas où poster ça alors le voici. Pour les signalements de bugs, merci de continuer sur le topic dédié : https://forums.infoclimat.fr/f/topic/7-bugs-sur-infoclimat-2/ Coup de fraîcheur sur les pages de climatologie globale, correction de quelques bugs et ajout de quelques graphiques : https://www.infoclimat.fr/climatologie/globale/paris-montsouris/07156.html Sur les pages de climatologie globale par mois, ajout des années des records : https://www.infoclimat.fr/climatologie/globale/mois-de-novembre/paris-montsouris/07156.html Uniformisation progressive du design des pages de climatologie avec ajout d'un bandeau de métadonnées sur les pages des normales. Les normales des stations du réseau secondaire sont en cours d'ajout : https://www.infoclimat.fr/climatologie/normales-records/1981-2010/lille-lesquin/valeurs/07015.html Toujours en cours mais moins visible, nous corrigeons progressivement les algorithmes de calcul climato, combinons d'autres sources de données, pour éliminer un maximum d'erreurs ponctuelles que vous pouvez observer sur les tableaux (RR délirants, neige en août, TX extravagantes,...). C'est un travail de fourmi et les résultats ne sont que progressifs. Fred
  7. Fred59_

    Suivi des changements sur Infoclimat

    Sur les pages de la climatologie annuelle, les écarts aux normales sont désormais mieux mis en valeurs et ont été ajoutés pour certains paramètres (pensez à passer la souris sur les étiquettes affichant l'écart aux normales). Sur les graphiques en bas de page, des informations complémentaires ont été ajoutées sur les écarts aux normales sur toute l'année : https://www.infoclimat.fr/climatologie/annee/2018/marseille-marignane-marseille-provence/valeurs/07650.html https://www.infoclimat.fr/climatologie/annee/2018/marseille-marignane-marseille-provence/phenomenes/07650.html Des ajouts sont encore en cours...
  8. Fred59_

    Suivi des changements sur Infoclimat

    Voir le début de la discussion ici :
  9. Malheureusement il ne faut pas chercher du côté de l'obfuscation, car ça ne fait que ralentir l'attaque sans jamais vraiment l'empêcher. Dans ce contexte il est très difficile de faire quoi que ce soit : les informations confidentielles doivent, à un moment ou à un autre, être connues de PHP pour effectuer les requêtes vers Weatherlink, donc a minima présentes dans la mémoire du serveur. Donc, si l'objectif c'est de protéger les informations contre une attaque "extérieure au serveur", tu peux conserver le fichier var.enc mais en mettant des règles htaccess ou nginx qui permettent d'empêcher l'accès à ce fichier (il suffit peut-être de le renommer ".var.enc", le point est souvent synonyme de fichier caché). Mais c'est généralement la piste adoptée par les logiciels opensource de ce type : une clé unique est générée au premier démarrage, stockée dans un fichier de config (généralement PHP pour éviter son téléchargement direct), et les éléments sont chiffrés avec. Généralement la crypto asymétrique ne résout rien au problème, puisque les informations à protéger doivent être accessibles à la fois en lecture et en écriture. Si par contre l'objectif c'est de se protéger d'une attaque issue d'un administrateur du serveur (hébergement mutualisé), il n'y a pas de solution. Un bon article récapitulatif sur le sujet : https://www.codementor.io/ccornutt/keeping-credentials-secure-in-php-kvcbrk55z Qui démontre bien que, quoi qu'on fasse... la clé est quelque part
  10. Fred59_

    36ème rencontre nationale Infoclimat en Haute-Loire

    Les inscriptions sont ouvertes : https://asso.infoclimat.fr/rencontres/detail.php?id=28
  11. Damien, avec tout le respect que je te dois, je ne peux pas laisser passer ce message sans signaler que toute cette partie sécurité ne résout pas du tout le problème de base; comme tu le dis à la fin de ton paragraphe "Sécurité", ici tu ne réussis à faire que de l'obfuscation : rendre les données "compliquées" à récupérer, les encoder, les triturer pour qu'il faille récupérer plusieurs fichiers à la fois et se casser la tête. Je cite une des célèbres phrases de cryptographes, c'est que seule la sécurité de la clé est garante de la sécurité du système (le "principe de Kerckhoffs") : "a cryptosystem should be secure even if everything about the system, except the key, is public knowledge". A lire, ce e-book très pédagogique sur l'ingénierie de la sécurité, dispo gratuitement en ligne : https://www.cl.cam.ac.uk/~rja14/book.html Concrètement, sur MBell, tout ce qui "protège" le fichier var.enc, c'est les lignes 36/37 de settings.php : - la fonction RpKkHKldiSjPBjPNIysD($lfOHykjIZB) est en fait un nom compliqué pour dire return gzinflate( base64_decode( $r )) - le gros bout de base64 dans le eval() se décompresse ensuite en : <?php function IXTQTTfpNhWUuvqBdKcj($NYnLqSJHyp){ $r=base64_decode("Z3ppbmZsYXRlKGJhc2U2NF9kZWNvZGUoJE5ZbkxxU0pIeXApKQ=="); return eval("return $r;"); } eval('?>'.IXTQTTfpNhWUuvqBdKcj('hZFbb4IwAIXfTfwPDeFBk2WJuOxF0YxYYV6YCq3aZTGlRdAWLBcn+uvHnvYwE59PvnPJ6Q9VrJoN3Z59WG8z71NzyqOFMMqISDcw2Xs+z0LtywxoEb6+7HjITjxsacyI4/kRGVq794cuIpRRmLh5tIjOfrzH6GL/R3HXFWwzRu7I8gJJZIBxsoJVymHxjW78QJP3WwixPe1YhZdUt5lBHJbKLcFj6XU4XRoTRQ0paEJKvJaKI3UO1i4isKpWkFznQsKlkOet5F1qkIxt3BN1YBc5Uc6MUnj21qxrNxvDQf93PNDtCSf5+OC6VGTYTzNOVWI+mtUD+hQpd1QEeXGK8vAy2lPpX4AJ9LqPPLCdCK/Pd71rtNZ2LL+q0gQxLWLQenQAeLqf1+6B4eAH').'<?php '); ?> Donc même topo que précédemment, en débouchonnant tout ça gzinflate = base64_decode : <?php $GLOBALS["HtjBUVUqZknXEmfSTdqe"]=base64_decode("c2hhMjU2"); $GLOBALS["PgUqaEmNrgPguThfVUwG"]=base64_decode("V3NkcXFUNDBSblZlbVVmRExndEsvUzdiamIzeEVGK1BsSmxzL2ZHcnlYZVFlS1daQ2Jpa2lkamZtVWlpdUpubWNUZExxREZyMklEQkluYld3a2ZqcXNoaHE3UHgrc2tkSGY="); $GJdZrFiNNakqVTnqdapm=$GLOBALS["PgUqaEmNrgPguThfVUwG"]; $KUpNDsbrsogrewDfalTw = $public_key.$GJdZrFiNNakqVTnqdapm; $key_crypt = hash ($GLOBALS["HtjBUVUqZknXEmfSTdqe"] , $KUpNDsbrsogrewDfalTw); ?> Ce qui donne concrètement : <?php $key_crypt = hash('sha256', $public_key."WsdqqT40RnVemUfDLgtK/S7bjb3xEF+PlJls/fGryXeQeKWZCbikidjfmUiiuJnmcTdLqDFr2IDBInbWwkfjqshhq7Px+skdHf"); Où ici toute la confidentialité du fichier var.enc repose sur cette suite de lettres qui est une partie de la clé de déchiffrement ($public_key étant directement à la ligne 5 de var.enc). Conclusion : je pense que cette méthode est encore pire que de stocker en clair la clé dans le PHP. En effet, si l'accès à var.enc n'est pas désactivé sur le serveur (par exemple si l'hébergeur ne prend pas en compte le .htaccess car il utilise nginx, ou pour des raisons de sécurité), on peut directement le décoder. Si je prends exemple sur ton propre site, j'ai déterminé que ton mot de passe weatherlink se terminait par "6A", et que ton token weatherlink commençait par "ECF" et se terminait par "66". Juste en téléchargeant le code source y'a 15 minutes et en accédant au fichier var.enc. Tandis que si la clé était stockée en clair dans le PHP, je n'aurais rien pu récupérer car ton hébergeur aurait empêché le téléchargement du code source (puisqu'il l'exécute). Je te félicite néanmoins pour ton travail sur le reste, MBell est une belle (sans jeu de mots) initiative, mais je souhaitais néanmoins corriger le tir sur cet aspect sécurité pour qu'un visiteur qui tombe sur le forum soit au courant de ces imprécisions, notamment concernant la phrase de la doc "Cette double sécurité [...] rend absolument impossible à quiconque (même à moi) de [...] décrypter vos données d'identifications, même en cas de piratage de votre site." L'objectif de ton message n'est pas de t'accabler, et j'espère que tu considéreras cela comme à but pédagogique et n'en seras pas vexé. C'est aussi le principe de l'opensource ^^ Du coup, je pense qu'il faut bien préciser que le fichier var.enc soit inaccessible en lecture pour que ça fonctionne un peu mieux
  12. Fred59_

    Lettre d'informations et vœux 2019

    La raison, c'est que les comptes site et forum sont différents, donc le passage au groupe "adhérents" sur le forum est fait manuellement. Fred
  13. Fred59_

    Bugs sur Infoclimat #2

    Est-ce mieux désormais ? Il semble y avoir un problème de permissions dans le répertoire stockant les données CartIC, donc le problème ne se présentait que sur certains sets de données.
  14. Fred59_

    Bugs sur Infoclimat #2

    C'est relancé. Concernant la suppression des valeurs, cela fonctionne chez moi. Peux-tu indiquer sur quel set de données (envoie moi le lien vers la page du formulaire d'édition du set de données) tu travailles ? Merci. Attention, il faut bien que le champ "Valeur" soit vide (pas d'espace).
  15. Fred59_

    Bugs sur Infoclimat #2

    Le filtre "3 degrés" est désormais activé par défaut dans la climatologie mensuelle. Il est activé également dans la climatologie annuelle, mais cela nécessite un recalcul des valeurs.
  16. Fred59_

    Bugs sur Infoclimat #2

    En fait nous avions déjà implémenté ce fonctionnement mais il n'était pas activé par défaut : Avec filtre à 3 degrés : https://www.infoclimat.fr/climatologie-mensuelle/000C4/janvier/2019/marseille-corniche.html?filter3deg=1 Sans filtre : https://www.infoclimat.fr/climatologie-mensuelle/000C4/janvier/2019/marseille-corniche.html
  17. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    cf mon message de 14h40 qui est en train de corriger cela, ça calcule
  18. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    C'est un épineux problème que tu signales là ! Suite au passage, il y a deux semaines, vers une nouvelle version de notre serveur de base de données, une des optimisations que nous utilisions ne fonctionne plus correctement. Cela peut impacter pas mal de pages climato relatives aux extrêmes, je suis en train de corriger progressivement la méthode de calcul.
  19. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    Je ne trouvais pas la valeur non plus et je me suis dit "peut-être que Raph est passé par là", mais ça répond à ma question Par contre sur Jungfraujoch il y a un souci de calcul dans les moyennes (dû à un bug très ancien de l'algo), je suis en train de relancer les calculs et vais recalculer le pays en entier pour corriger ces bugs. Ça corrigera probablement aussi d'autres stations ailleurs.
  20. Fred59_

    Base climato

    Parce que nous ne disposons malheureusement pas de données sur cette période. Tu peux par contre voir ces records sur les fiches de normales/records : https://www.infoclimat.fr/climatologie/normales-records/1981-2010/le-mans-arnage/valeurs/07235.html edit: a priori on a les données il faut juste que je vérifie pourquoi elles ne sont pas intégrées dans la climato : https://www.infoclimat.fr/climatologie-mensuelle/07235/decembre/1964/le-mans-arnage.html
  21. Fred59_

    Bugs sur Infoclimat #2

    @acrid vintaquatre je vais voir ça ce week-end @frecel : c'est parce que, comme indiqué sur le graphique, à cette heure du jour, 1W/m² suffisent à dire qu'il y a de l'ensoleillement. Et comme la luminosité ambiante (=rayonnement global) est déjà de 5W/m² à cette heure, cela est comptabilisé comme de l'ensoleillement. Il faudrait que nous réfléchissions à une méthode pour gérer ce genre de cas, par exemple en instaurant une borne minimale.
  22. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    Je pense qu'en effet beaucoup s'imaginent la climatologie sur IC comme un énorme tableau excel bien rangé avec "jour / TN / TX / RR". Dans les faits, avec les nombreuses sources de données différentes, qui reportent sur des intervalles différents, à des moments différents de la journée, à combiner avec d'autres sources moins fiables mais de séries plus longues mais qui reportent des valeurs arrondies ou sur des créneaux non-OMM, les calculs ne sont malheureusement pas simples, et le besoin de générer de la climato annuelle sur un site aussi visité qu'IC sans que les pages mettent 20 secondes à charger nécessite de mettre en place du cache et du pré-calcul, ce qui accentue encore le risque d'incohérence et de desynchronisation, au profit de meilleures performances. Le tout en assurant une rétro-compatibilité, pour que les sources de données anciennes continuent de pouvoir être utilisées dans le calcul climato aujourd'hui comme en 2025... Bref, un casse-tête de tous les instants, mais parfois il suffit en effet d'un recalcul pour que les plus grosses erreurs soient corrigées, car elles datent d'anciennes versions des algorithmes (ce pourquoi d'ailleurs nous affichons désormais la date de dernier recalcul). Et parfois, comme pour les 0.1 degrés restants en question, l'erreur est plus subtile à trouver, mais progressivement nous les supprimons grâce a ces remarques que nous notons dans un bug tracker, mais qui ne peuvent être corrigées que de manière plus lente. C'est effectivement difficile de communiquer concrètement sur ces évolutions "de fond", car les bugs trouvés sur les algos n'impactent que de petits sets de données... Mais on voit bien en effet grâce aux recalculs quelques mois après que les chiffres s'améliorent d'eux-mêmes, sans intervention. D'ailleurs, sur les pays étrangers autres que la France, nous avons lancé tout un lot de recalculs de 1980 à 2010, et cela continue en tâche de fond... Et bientôt sur la France également. Edit: doublé par Laurent dont je plussoie le message
  23. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    C'était une image de l'esprit, le bus. Cependant, si tu savais le nombre de lignes de code d'IC qui ont été tapées sur un coin de table, dans des bus ou des trains, à l'arrière d'une bagnole sur 2h de trajet pour aller dépanner une station en panne, ou dans des conditions complètement farfelues et pas du tout sérieuses, j'imagine que tu ne viendrais plus sur IC ! Pardon de ne pas être Météo-France. Pardon de ne pas avoir Infoclimat comme travail. Pardon de ne pas avoir une hotline 24h/24 de correction de bugs sur 4 milliards de lignes de base de données. C'est vrai, nous sommes vraiment décevants. Et l'erreur de la Tmm sur l'année 2018 a été corrigée, il me semble... Et en plus, Raph avait noté les valeurs toujours erronées pour pouvoir les corriger un peu plus tard...
  24. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    Oui, parce que tu as peut être le temps de recalculer la climato manuellement sur des dizaines d'années, mais Raph a sûrement fait la modif entre deux bus en allant au taf (ou que sais-je), rapidement après la publication de ton message, et son action a corrigé 90% des valeurs, les erreurs que tu cites ne sont plus que des erreurs de 0.1 degré, soit même pas la précision de mesure de l'instrument. Alors tu pourrais en effet faire preuve de plus de retenue dans tes réactions à chaud. D'autant que les valeurs n'ont pas été corrigés à la main, seulement un recalcul a permis de corriger les valeurs les plus erronées. Je n'appelerais donc pas ça une correction a la va-vite (terme que je trouve péjoratif), mais un moyen d'effectuer une première correction en attendant un correctif plus poussé pour ces dixièmes d'erreur restants. Je respecte ton exigence au plus haut point concernant la précision des informations présentées, mais je désapprouve complètement tes réactions envers l'équipe qui abat un travail que tu n'imagines que difficilement, sur son temps libre.
  25. Fred59_

    Bugs sur Infoclimat #2

    Il suffit de te connecter à ton compte sur le site depuis ton mobile.
×