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 065
  • Inscription

  • Dernière visite

1 abonné

À propos de Fred59_

  • Rang
    « Chef des robots d'Infoclimat »
  • Date de naissance 30/11/1993

Personal Information

  • Lieu
    Noisy-le-Sec (93)

Visiteurs récents du profil

1 767 visualisations du profil
  1. Fred59_

    Aidez nous à recenser les erreurs de notre base climatologique

    Le problème ne vient pas d'infoclimat mais de la source de données, qui ne reporte pas la TN à 18h UTC, mais seulement à 6h UTC. Je ne me souviens pas avoir évoqué ce problème spécifique ? Il faut que l'on regarde si d'autres sources de données ne fournissent pas de plus amples détails pour les TN, en attendant en effet il faudrait pouvoir utiliser les données de température chaque heure, avec les soucis de fiabilité que cela implique pour les vieilles séries de données. PS: quel est le rapport avec la TNM ?
  2. 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.
  3. Bonjour, Non, ce n'est pas possible pour le moment.
  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. 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...
  7. Fred59_

    Suivi des changements sur Infoclimat

    Voir le début de la discussion ici :
  8. 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
  9. Fred59_

    36ème rencontre nationale Infoclimat en Haute-Loire

    Les inscriptions sont ouvertes : https://asso.infoclimat.fr/rencontres/detail.php?id=28
  10. 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
  11. 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
  12. 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.
  13. 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).
  14. 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.
  15. 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
×