Discussion :

[saxrub]

Bonjour

On me signale que les cartes ne s'affichent plus ce matin.

Par exemple pour la même page geoportail_quel_lieudit5.php

la carte ne s'affiche pas pour https://wnat.fr/geoportail_quel_lieudit5.php
mais s'affiche pour https://visiolittoral.fr/geoportail_quel_lieudit5.php

Vous me direz, c'est un problème de licence ! La licence 8g7vs7bw026v3dfqgkpezol8 pour wnat.fr expire le 25/06/2019

Par contre, la page https://wnat.fr/geoportail_quel_lieudit5.php génère l'erreur TypeError: Geoportal.Catalogue.TERRITORIES[e] is undefined[En savoir plus]

Une aide rapide me serait très agréable !

Pascal

[IGNC_XT]

Ce matin, il y a eu une défaillance du service d'autoconf. A midi c'était résolu
Nous recommandons de conserver le fichier de configuration en utilisant la méthode décrite dans le paragraphe Optimisation du chargement : configuration locale de la page suivante : https://geoservices.ign.fr/documenta...%C3%A9oportail

[saxrub]

Bonjour
Dans l'après-midi, je m'étais rendu compte que les cartes s’affichaient de nouveau !
Ton conseil de configuration ne vaut que pour la dernière version de l'API, mais malheureusement, toutes mes pages ne sont pas migrées par faute de temps (et de conséquences potentielles).
Pour signaler un problème tel que celui d'hier, y a-t-il un autre canal d'alerte que le forum ?
Pascal
PS : je fermerai l'incident après votre réponse.

[IGNC_XT]

Même recommandation pour les anciennes API : https://depot.ign.fr/geoportail/api/...ur/geodrm.html
Après pour le support : https://geoservices.ign.fr/support/#...client-de-lign
et l'adresse donc contact.geoservices@ign.fr

[saxrub]

On vient de me signalé que les cartes ne s'affichent plus et génèrent le même code erreur

[ep_dev]

Bonjour,

Depuis le 28/01/2019 l'accès au webservice de géocodage à partir d'une adresse ne fonctionne plus.
Aujourd'hui, lorsque je me connecte au geoportail pour afficher des cartes via l'ancienne API ou la nouvelle (OL3), je n'obtiens rien : l'imagette d'attente tourne indéfiniment. Il ne semble pas que ce soit lié aux clefs (contrats) puisqu'elles sont actives.

J'ai lu qu'il y avait un problème de serveur de configuration ; j'ai suivi votre conseil en me rendant à l'adresse : http://ignf.github.io/geoportal-acce...getconfig.html et en saisissant une clef de contrat mais la page ne semble pas répondre.

Pouvez-vous nous informer plus précisément sur les problèmes en cours ? l'existence de contournements possibles ?

Bien cordialement,
EP

[IGNC_XT]

Bonjour,
Il y a eu une migration de l'infrastructure.
Les appels en https sont à privilégier. Les appels http direct ont été rétablis mais nous recommandons le https.
L'API V2 est dépréciée depuis 2017...
Sur vos sites avec les nouvelles extensions geoportail avez-vous un lien pour qu'on puisse regarder ?

A noter toutefois que certaines ressources (cf. blog) sont pour l'instant indisponibles mais que le nécessaire est fait pour éviter que la situation ne perdure.

[ep_dev]

Bonjour,

Notre appel au webservice de géocodage d'adresse : http://wxs.ign.fr/<<KEY>>/geoportail/ols?xls=<<adresse formatée en XML>> ne fonctionne plus.. y-a-t-il eu des changements ? L'URL a-t-elle changé ? La structure du XML de la requête que l'on soumet a-t-elle changé ?

Certaines de nos cartes utilisent toujours OL2 ; Votre migration a-t-elle débranché définitivement l'API V2 ?

Bien cordialement,
EP

[IGNC_XT]

Passer en https et ça devrait fonctionner

[ep_dev]

Bonjour,

Le fait de passer en https ne résout rien en ce qui concerne les requêtes de géocodage par adresse (voir url de mon précédent message)
Est-ce lié au problème d'autoconf ?

Bien cordialement,
EP

[vremac]

Bonjour,

Le service est indisponible ce matin, cela fait-il partie des soucis indiqués ici ? : https://geoservices.ign.fr/blog/2019...urbations.html

Autre point, mon application interroge le service OPENLS à partir d'un client Java et cela dysfonctionne depuis au moins deux semaines.

Y-a-t-il eu des changements sur ce service, qui nécessiteraient des adaptations de notre client ? (changement d'URL, format des flux...)

Bien cordialement,
Vincent.

[ep_dev]

Bonjour,

Idem pour nous via une appli sous .net (HttpWebRequest). L'appli ne fonctionne plus depuis la migration..

Cordialement,
EP

[IGNC_XT]

@VREMAC
Cela dépend de la version de Java. Apparemment certaines versions ne supportent pas le TLSv1.2...

@EP_DEV
Je pense que c'est le même problème. Pour activer le TLS 1.2 cf. https://support.microsoft.com/fr-fr/...ration-manager

[dom73]

Bonjour

J'ai aussi un problème intermittent d'affichage des cartes sur une page simple : j'utilise la V3 et j'utilisais "data-key" au chargement du plugin OpenLayers
Donc, comme conseillé sur le blog (https://geoservices.ign.fr/blog/2019...turbation.html), j'ai généré un fichier "autoconf.json" que j'héberge en local
Malgré ça, l'affichage des cartes est très irrégulier, extrèmement long voire impossible
J'ai régulièrement le message d'erreur "[AutoConfResponseReader] autoconf response xmlns:gpp namespace is not the expected one"

Est-ce qu'il faut juste attendre que les services soient stabilisés ou est-ce que je dois modifier d'autres paramètres ?

Merci

[vremac]

Bonjour,

Le client java pour l'interrogation du WS OpenLS utilise Java 8u201, qui intègre bien le protocole TLS v1.2.
Après investigation plus poussée, le souci provient du fait que le certificat serveur utilisé ne fait pas partie du truststore Java par défaut.

Afin de corriger le souci, il est nécessaire lors de l'établissement de la connexion HTTPS d'utiliser un truststore qui intègre le certificat serveur OpenLS (soit en créer un dédié, soit modifier celui par défaut de Java).

De mon côté je n'ai pas vu de communication officielle sur ce sujet (je l'ai peut-être ratée).
Ce point est très dommageable dans la mesure où des fonctionnalités en production cessent de fonctionner du jour au lendemain, sans avertissement préalable.

À noter en revanche que cette manipulation permet de réparer les accès à OpenLS, mais les cartes ne semblent toujours pas fonctionner.

Bien cordialement,
Vincent.

[ep_dev]

Bonjour,

Le framework installé est le 4.7 (TLS 1.2 actif par défaut). Nous avons suivi les recommandations accessibles depuis le lien : https://support.microsoft.com/fr-fr/help/4040243/how-to-enable-tls-1-2-for-configuration-manager.

Nous obtenons toujours une erreur 500 Internal Server Error / Protocol Error. Cette même application accède à d'autres url https sans problème et l'url formulée obtient bien une réponse de l'IGN lorsqu'elle est exécutée directement depuis le navigateur.

Quelqu'un a-t-il une autre piste ?

Bien cordialement,
EP

[vremac]

Bonjour,

Vous est-il possible d'obtenir les traces applicatives d'établissement de la connexion sécurisée ?
(En java il s'agit d'activer l'option -Djavax.net.debug=all au démarrage de la JVM mais je ne connais pas l'équivalent pour vous).

Avec ces traces vous devriez pouvoir déterminer exactement ce qui pose problème (protocole ? magasins de certificats ? autre ?).

Bien cordialement,
Vincent.