Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Philippe Verdy 
Note que le gros des tests et déploiement de SoH en ce moment dépend de
serveurs mis en place par CloudFlare.
Hors CloudFlare c'est jsutement une des grosses victimes de la méga-panne
de Level3 (au moins en Europe).

ce qui marche plutôt pour l'instant (mais pas encore massivement déployé)
c'est DoT (DNS over TLS, plutôt TLS 1.3), IPSEC.

Il manque encore des composants essentiels: SNI, et surtout le déploiement
d'IPv6 qui est encore largement insuffisant pour servir le monde (et
notamment les IoT qui se développent à grande vitesse dans l'anarchie la
plus complète et sans grand contrôle et même en dépit des règles légales
concernant leur sécurité, la confidentialité, l'absense totale de contrôle
par l'utilsiateur tant ils sont opaques, jamais maintenus, et pas
désactivables).

DoH pour moi n'a aucune chance de marcher sans IPv6 partout (Note:
Microsoft est en train de supprimer de Windows le support des tunnels IPv6
pour la transition: 6to4, Teredo, etc. sont officielement listés comme
n'étant plus maintenus, et les serveurs de Microsoft qui les
supporte encore sont en forte déduction de capacité). Microsoft semble
faire ça pour forcer les FAI a enfin mettre à jour leurs box ou les
remplacer (mais dans de nombreux pays, les box ne sont pas fournis ni gérés
par les FAI, ils sont achetés et ceux qui les vendent ne les
maintiennent pas non plus, il y a beaucoup de produits défectueux et non
conformes dans ce qu'on trouve en ligne dont nombre de vendeurs chinois, et
même chez de nombreux importateurs qui achète juste sur catalogue et
livrent tels quels)

De fait aussi, nombre de'utilisateurs désactivent le support d'IPv6 sur
leur matériel parce qu'ils jugent qu'ils n'en ont pas besoin, ou parce
qu'un vendeur de VPN leur a dit que c'était nécessaire et qu'ils
"s'occupaient de tout" à leur place. Les VPN sont une arnaque commerciale
presque partout, avec de fausses promesses de sécurité, de confidentialité
ou d'optimisation des performances.

Que dire encore des FAI et fournisseurs de services français qui tardent
encore à déployer IPv6 (à peine 35% d'entre eux ont une allocation et un
bloc routable, mais au final ils ne les utilisent même pas pour leurs
clients et préfèrent déployer IPv6 à travers de tunnels IPv4 propriétaires,
bien plus lent donc que l'IPv4 natif). Orange en particulier ne fait pas
grand chose. Pas plus SFR. Seul Free semble avoir une offre native
dual-stack par défaut pour tout le monde (libre ensuite à chacun de le
désactiver s'il le veut). Et rien du tout concernant l'Internet mobile.

En fait tout ce monde là préfère vendre ses services en fournissant un
service DNS dont ils contrôlent et filtrent le contenu, et ils en supprime
la sécurité (aucune authentification, ils en profitent pour détourner du
trafic: Orange et SFR notamment). Et que dire des offres des FAI français
qui imposent l'usage (location ou achat) de leur modèle de box supporté
uniquement chez eux et dont ils controlent totalement le firmware (même sur
les box achetées et non louées). L'internet transparent et égalitaire n'est
pas une réalité, il est même de plus menacé, filtré, comme autant de
réseaux propriétaires où on voit ce que le fournisseur veut bien laisser
passer.

Dans ces conditions, IPv6 ne décolle pas. Et tout le monde continue de
dépendre sur des services IPv4 dont on peine à les maintenir en vie et à
les sécuriser: Internet est de plus en plus grévé d'erreurs de securité et
de défauts de maintenance, mais tout le monde "tolère" ça car en plus ces
problèmes servent à booster des ventes d'autres produits dits "de
sécurisation" (les VPN sont la dernière invention inutile, alors qu'ils
n'étaient au départ qu'une solution transitoire d'interconnexion, pas
destinée à optimiser les performances ni réellement apporter une vraie
sécurité auditable).

Bref j'ai de gros doute sur le fait de déployer DoH pour l'instant.
L'Internet n'est pas prêt (en tout cas même pas en France, il l'est
juste dans certains petits pays comme le Luxembourg, mais ces même pays
dépendent très largement de contenus et services qui ne sont pas
accessibles en IPv6, même en vitesse lente pour seulement envisager d'y
héberger DNS sur HTTPS ou TLS: meêm sans TLS, le DNS non sécurisé sur TCP
est tout aussi lent et sous-dimensionné, il n'y a pas assez de serveurs,
même en IPv4, et encore moins en IPv6 où pourtant ce serait plus facile
avec plein de ports et des milliards d'IP uniques pour multiplier les ports
sans nécessiter d'installer une multitude d'interfaces réseau et leur
allouer de très couteuses IPv4).

Si je reviens aux VPN, ils sont presque tous conçus pourtant pour héberger
leur tunnel en IPv4 (il n'y a pas assez de serveurs de tunnels en IPv6).

Il y a bien une parade: faire du TLS avec une encapsulation de TCP sur UDP
(solution déjà utilisée pour le streaming sur certains services).

Mais les gros sites fournisseurs ou hébergeurs de vidéos eux préfèrent
encore l'HTTP(S) sur IPv4 via des serveurs miroirs négociés chez les
fournisseurs d

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Denis Chenu via Talk-fr 
Je gère des serveurs dont des serveurs DNS,

Cependant : je ne me permettrais ni d'évaluer la qualité technique de DOH.
Je laisse cela à des personnes compétentes.

Denis
Le 04/09/2020 à 15:18, Philippe Verdy a écrit :
> Ce n'est toujours pas complètement réglé. Notamment des fournisseurs
> de DNS sécurisés (dont bon nombre de services DNS over HTTPS qui
> perdent leurs sessions et on beaucoup de mal à les reconencter) sont
> toujours impactés.
>
> Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou
> par Microsoft sous Windows 10, mais visiblement il n'a pas encore la
> capcité nécessaire de supporter le traffic nécessaire: les serveurs
> DOH "tombent" les uns après les autres par surcharge (plus assez de
> ports TCP). A mon avis le DOH est une mauvaise solution (à cause de
> l'utilisation de TCP) et le plus fiable reste encore le DNS sur UDP
> qu'on peut authentifier malgré tout avec les signatures numériques et
> les certificats PKI.
>
> J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez
> Cogent (et sur certaines passerelles de Cogent vers
> l'Afrique transitant par OpenTransit/Orange). Là encore il y a
> toujours un problème (et certains pays africains sont encore quasi
> coupés du monde (il y a aussi des problèmes ailleurs comme en Syrie ou
> Corée du Nord, mais là c'est beaucoup plus lié aux mesures politiques,
> ou des mesures d'urgence dans la cyberguerre qui se déroule en ce
> moment, que ce soit entre US et Chine, ou Chine et Taiwan, et en fait
> pas tellement pour ce qui concerne la situation politique locale,
> puisque même les groupes violents ou extrémistes ont besoin de ces
> réseaux et ne les sabottent pas, bien au contraire, même s'ils veulent
> en prendre le contrôle pour pouvoir les utiliser encore davantage: les
> mesures prises le sont par leurs voisins).
>
>
> Le ven. 4 sept. 2020 à 09:39, Christian Quest  > a écrit :
>
> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était
> extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink,
> un gros
> fournisseur de tuyaux.
>
> 
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> -- 
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Philippe Verdy 
Ce n'est toujours pas complètement réglé. Notamment des fournisseurs de DNS
sécurisés (dont bon nombre de services DNS over HTTPS qui perdent leurs
sessions et on beaucoup de mal à les reconencter) sont toujours impactés.

Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou par
Microsoft sous Windows 10, mais visiblement il n'a pas encore la
capcité nécessaire de supporter le traffic nécessaire: les serveurs DOH
"tombent" les uns après les autres par surcharge (plus assez de ports TCP).
A mon avis le DOH est une mauvaise solution (à cause de l'utilisation de
TCP) et le plus fiable reste encore le DNS sur UDP qu'on peut authentifier
malgré tout avec les signatures numériques et les certificats PKI.

J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez Cogent
(et sur certaines passerelles de Cogent vers l'Afrique transitant par
OpenTransit/Orange). Là encore il y a toujours un problème (et certains
pays africains sont encore quasi coupés du monde (il y a aussi des
problèmes ailleurs comme en Syrie ou Corée du Nord, mais là c'est beaucoup
plus lié aux mesures politiques, ou des mesures d'urgence dans la
cyberguerre qui se déroule en ce moment, que ce soit entre US et Chine, ou
Chine et Taiwan, et en fait pas tellement pour ce qui concerne la situation
politique locale, puisque même les groupes violents ou extrémistes ont
besoin de ces réseaux et ne les sabottent pas, bien au contraire, même
s'ils veulent en prendre le contrôle pour pouvoir les utiliser encore
davantage: les mesures prises le sont par leurs voisins).


Le ven. 4 sept. 2020 à 09:39, Christian Quest  a
écrit :

> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros
> fournisseur de tuyaux.
>
>
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-04 Par sujet Christian Quest 

Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
oui ça remarche ce midi, hier soir l'internet était un enfer à 
naviguer. (sauf les sites Google, et le reste était extrèmmeent lent, 
surtout le DNS et presque tout ce qui transitait par les gros 
datacenters d'Amsterdam)



Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros 
fournisseur de tuyaux.


https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet


La concentration d'internet dans toute sa splendeur :(

--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-01 Par sujet Philippe Verdy 
oui ça remarche ce midi, hier soir l'internet était un enfer à naviguer.
(sauf les sites Google, et le reste était extrèmmeent lent, surtout le DNS
et presque tout ce qui transitait par les gros datacenters d'Amsterdam)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-09-01 Par sujet osm . sanspourriel 

J'ai vu le même soucis mais plus tôt dans la soirée et sous FF 80.

Et plus tard c'est retombé en marche.

Jean-Yvon

Le 01/09/2020 à 07:29, Philippe Verdy - ver...@gmail.com a écrit :


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Philippe Verdy 
Tout ça ressemble à des échecs de connectivité entre les différents
services. visiblement ce 1er septembre à 0h00 UTC a été une date butoir
pour le début de renforcement de la sécurité d'un certain nombre de
services (déjà annoncé pour bientôt, la déprécation du DNS sur UDP,
remplacé par le DNS sur HTTPS, mais déjà effectif la fin du "mixed
content", autrement dit les sessions HTTP en arrière-plan depuis une
session HTTPS, et un certain nombrede certificats anciens révoqués car avec
une signature de sécurité insuffisante; bientôt aussi DNSSEC, des
migrations sur le ROOT DNS vers IPv6 natif, avec support d'IPv4 uniquement
par des proxies locaux, et une refonte de la connectivité générale de
l'internet, une refonte des relations d'approbation et d'aggrégation, et
des protocoles d'annonces interréseaux pour mieux les sécuriser et les
reponsabiliser, des renforcements du QOS et des règles d'équilibrage au
sein des backbones et dans les datacenters, avec une politique de quotas
plus stricte).
Au passage un certain nombre de vieilles RFC ne seront plus supportées.

Passage obligé pour renforcer la sécurité mlais il y aura de la casse, et
on en aura d'autres car la lutte ne s'arrête pas là, et même les agences
spécialisées ou groupes d'agences comme CVE ont beaucoup de mal à suivre et
ne peuvent même plus référencer seulment les attaques connues. La
cybercriminalité gagne sans cesse du terrain et est devenue une arme d'état
avec de très gros moyens déployés contre lesquels les lois ou la justice ne
suivent pas non plus, c'est l'impunité quasi totale sauf contre quelques
sous-fifres. En attendant ça coute cher à tout le monde et on en paye le
prix, avec de plus en plus d'exclusion de garanties et des délias de
recours de plus en plus courts pour récupérer des miettes de ce qu'on a
perdu. Et le tout profite autant qux cybercriminels qu'aux gros acteurs de
l'Internet qui ne cessent de vendre de nouvelles solutions sensées être des
parades mais sans offrir de réelle garantie en échange. C'st du chacun pour
soi et tant pis si la plupart des gens ne comprend pas ce qui se passe
tellement c'est technique et compliqué (d'autant plus que derrière ça il y
a beaucoup de secrets et de failles tues : on ne peut même plus réellement
mesurer le risque réel, ce qui permet aux vendeurs de pousser à nous faire
acheter des protections illusoires voire encore plus dangereuses, dont les
vendeurs de VPN et divers outils inutiles qui rajoutent leurs propre
failles). Pendant ce temps là les logiciles et OS ne cessent d'enfler de
fonctions inutiles préinstallées mais pas réglées comme il faut. Et la
télémétrie n'a jamais été aussi intrusive pour détourner nos données et
ajouter des failles sur leur collecte ou leur stockage et gestion par des
tas de tiers inconnus).

Fin bon, là  je m'écarte du sujet. Mais il y a bien quelquechose qui a
changé cette nuit, car ça ne touche pas qu'OSM: les performances globale du
DNS ont changé radicalement aussi cette nuit si j'en crois ce que je vois
sur le réseau de mesure de RIPE NCC et ça va au delà des problèmes de
"Mixed content" dans Chrome (je le vois aussi avec d'autres navigateurs et
sur mobile avec un autre FAI).




Le mar. 1 sept. 2020 à 06:55, Yves P.  a écrit :

> Voyez-vous la même chose ?
>
>
> L'affichage de la page d'un utilisateur :
> Application error
>
> The OpenStreetMap server encountered an unexpected condition that
> prevented it from fulfilling the request (HTTP 500)
>
> Feel free to contact  the
> OpenStreetMap community if your problem persists. Make a note of the exact
> URL / post data of your request.
>
> This may be a problem in our Ruby On Rails code. 500 occurs with
> exceptions thrown outside of an action (like in Dispatcher setups or broken
> Ruby code
>
> Je réessaie avec la mienne :
> We're sorry, but something went wrong.
>
> The issue has been logged for investigation. Please try again later.
> Technical details for the administrator of this website
> 
> This website is powered by Phusion Passenger
> ®,
> the smart application server built by *Phusion*®.
>
> Je recommence, elle s'affiche mais pas les icônes de certains "amis".
> Une autre réactualisation de la page : de nouveau le message de Phusion
>
> Bref, le serveur patauge dans la semoule…
>
> Est-ce un problème propre à OSM ou un effet de bord d'un problème plus
> général sur internet ?
> Hier, le flux vidéo était figé par moment avec des pertes de son sur la
> télé (box sur ADSL).
>
> __
> Yves
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Yves P. 
> Voyez-vous la même chose ?

L'affichage de la page d'un utilisateur : 
Application error

The OpenStreetMap server encountered an unexpected condition that prevented it 
from fulfilling the request (HTTP 500)

Feel free to contact  the 
OpenStreetMap community if your problem persists. Make a note of the exact URL 
/ post data of your request.

This may be a problem in our Ruby On Rails code. 500 occurs with exceptions 
thrown outside of an action (like in Dispatcher setups or broken Ruby code


Je réessaie avec la mienne : 
We're sorry, but something went wrong.
The issue has been logged for investigation. Please try again later.

Technical details for the administrator of this website 

This website is powered by Phusion Passenger 
®, the 
smart application server built by Phusion®.

Je recommence, elle s'affiche mais pas les icônes de certains "amis".
Une autre réactualisation de la page : de nouveau le message de Phusion

Bref, le serveur patauge dans la semoule…

Est-ce un problème propre à OSM ou un effet de bord d'un problème plus général 
sur internet ?
Hier, le flux vidéo était figé par moment avec des pertes de son sur la télé 
(box sur ADSL).

__
Yves


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Philippe Verdy 
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  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  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|DU0D7B|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  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  a
>>> écrit :
>>>
 Ce soir je note q

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Philippe Verdy 
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  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|DU0D7B|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  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  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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Philippe Verdy 
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|DU0D7B|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  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  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

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Philippe Verdy 
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  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

[OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

2020-08-31 Par sujet Philippe Verdy 
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