Dernier symptôme constaté: l'icone en tête de la barre d'adresse affiche un problème de sécurité. Il y a une tentative échouée de géolocalisation par IP via une requête HTTP (qui est bloquée par le navigateur).
Cela semble affecter de la même façon que le logo Bing. iD ne fonctionne plus correctement en mode "mixed content", que Chrome maintenant refuse plus strictement qu'avant (Google l'avait annoncé il y a quelques mois, c'est maintenant effectif au 1er septembre et c'est pile synchrone à l'heure dite 1er septembre à partir de 0h00 UTC): si on est en HTTPS, toutes les ressources chargées en arrière plan doivent avoir le même niveau de sécurité en HTTPS. Le mar. 1 sept. 2020 à 02:06, Philippe Verdy <ver...@gmail.com> a écrit : > ET je pense que c'est lié au renforcement de la politique de > "Mixed Content" dans la version 85 de Chrome: l'image "http:// > dev.virtualearth.net\/Branding\/logo_powered_by.png" se charge sans > problème dans une session web séparée (dans une autre fenêtre) de même en > HTTPS. Mais pas en mode "mixed content" avec une session iD en HTTPS qui > demande des ressources par des XHR en HTTP. > > Et ça semble être bloquant même pour charger des données OSM qui n'ont pas > pas besoin du tout de cette ressource. > > > Le mar. 1 sept. 2020 à 02:03, Philippe Verdy <ver...@gmail.com> a écrit : > >> autre symptome; virtual.net indique semble-t-il une erreur de Bing (même >> si Bing n'est pas l'imagerie utilisée). >> >> {"authenticationResultCode":"DeniedCredentials","brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png","copyright":"Copyright >> © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be >> accessed and the content and any results may not be used, reproduced or >> transmitted in any manner without express written permission from Microsoft >> Corporation.","errorDetails":["The request was forbidden. Your credentials >> may be denied or >> suspended."],"resourceSets":[],"statusCode":403,"statusDescription":"Forbidden","traceId":"55dd5c79c6ba4e86b47c24ddc16c35b4|DU00000D7B|0.0.0.1"} >> >> Bing rejette la requête ou aurait suspendu ses autorisations pour OSM >> (pourtant je vois bien l'imagerie Bing, mais en résolution bien plus >> limitée qu'avant). >> >> Je ne comprend pas d'ailleurs pourquoi Bing intervient dans le chargement >> des données OSM, quand on ne l'utilise pas du tout comme imagerie de fond >> (ici je veux utiliser la BDORtho qui est celle présélectionnée pour la >> zone). >> >> D'ailleurs je peux changer le fond de carte et choisir n'import quel >> autre, je n'ai toujours aucune données OSM qui se charge, et toujours cette >> erreur de "virtuelearth" concernant le chargemetn de son logo et qui >> ensuite semble produire une erreur empêchant de traiter les données OSM >> demandées (bogue sans doute d'un des javascript d'iD)... >> >> Ca marchait très bien il y a moins de 2 heures. iD a donc changé >> inopinément sur le serveur OSM.org. >> >> J'ai essayé de fermer la session OSM et me réauthentifier après avoir >> purgé et fermé le navigateur. Ca ne répare pas. >> >> >> Le mar. 1 sept. 2020 à 01:51, Philippe Verdy <ver...@gmail.com> a écrit : >> >>> Note aussi: bien que je vois l'imagerie (source: >>> proxy-ign.openstreetmap.fr), la console du navigateur affiche plein >>> d'erreurs HTTP 404 (NOT FOUND) sur de nombreuses tuiles. >>> >>> Je ne vois pas cependant ce qui empêche de charger les données OSM qui >>> viennent d'un autre serveur, à moins que les nombreuses tentatives de >>> chargement de tuile en arrière-plan ne vienne saturer la quantité maximale >>> de "worker threads" dans le navigateur pour les requêtes XHR asynchones. >>> >>> Sachant aussi que dans cette configuration je note des >>> restrictions appliquées par le navigateur pour cause de "mixed security" >>> (requêtes HTTP asynchrones sur une session HTTPS) pour charger certains >>> composants (notamment ceux de la plateforme IGN pour quelques >>> éléments statiques, comme son logo qui n'est pas chargé et donc pas affiché >>> en bas de page, et un composant mystérieux de "dev.virtualearth.net" >>> lui aussi en échec). >>> >>> Cela semble indiquer un problème de configuration pour servir les >>> orthophotos IGN avec le serveur OSM France. >>> >>> Et je vois l'icone molette (chargement en court) qui "tourne" en continu >>> et ne s'arrête jamais dans le bas de la page. >>> >>> Symptôme: >>> id-cb964615435368f8fd15fc4af176ca66abba4a61440ac06478b8c75f0fd51ef7.js:2 >>> Mixed Content: The page at ' >>> https://www.openstreetmap.org/edit?relation=10895122#map=19/46.32429/-0.46743' >>> was loaded over HTTPS, but requested an insecure image ' >>> http://www.ign.fr/institut/sites/all/themes/ign_institut/logo.png'. >>> This content should also be served over HTTPS. >>> >>> La requête est vient d'une sous-requête lancée par le serveur OSM.org >>> avec une référence invalide. L'IGN aurait changé sa config récemment ? >>> >>> >>> >>> Le mar. 1 sept. 2020 à 01:33, Philippe Verdy <ver...@gmail.com> a >>> écrit : >>> >>>> Ce soir je note que l'éditeur iD semble avoir un problème: il ne >>>> télécharge aucune des données quand on entre en édition ou bien il faut >>>> attendre de nombreuses minutes, puis dézoomer et zoomer encore, on obtient >>>> seulement une partie des données, ce qui peut faire croire que c'est >>>> incomplet. >>>> >>>> Je peux vider le cache du navigateur, cela n'a pas d'effet. >>>> >>>> Sur d'autres éditeurs aussi le serveur semble retourner des données >>>> incomplètes ou carrément vides. Je ne m'explique pas bien les choses car il >>>> n'y a aucune erreur relevée (pas d'erreur de statut HTTP, pas de statut >>>> d'erreur non plus dans la réponse du serveur, on dirait que la session est >>>> juste tronquée entre le frontal et le backend. >>>> >>>> De plus je constante une désynchronisation (les timestamps ne >>>> correspondent pas, comme si un cache quelquepart sur un serveur frontal >>>> était corrompu). >>>> >>>> Inutile de dire qu'éditer en ce moment est plutôt problématique et >>>> qu'on risque de faire des dégâts. >>>> >>>> Voyez-vous la même chose ? >>>> >>>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr