Clé web qui ne fonctionne

Version imprimable

30/01/2015, 10h38
kintha

Clé web qui ne fonctionne

Bonjour,

Nous avons reçu une clé WEB pour notre environnement de production.
Cette clé à été demandée pour fonctionnait sur plusieurs environnements.
Après avoir modifié la clé temporaire par cette clé, un environnement qui utilisait cette clé n'arrive plus à charger l'API IGN.
Pourriez vous nous dire ce qui pourrait poser problème ?

Pour info, l'appel de l'API se fait via une URL avec un port en 8081. Or la clé a été configurée pour l'URL sans le port 8081. Est-ce que cela peut poser un souci ?

Merci d'avance de votre réponse.
30/01/2015, 10h55
gcebelieu

Bonjour,

vous devriez pouvoir consulter et modifier la configuration de votre clef via votre compte sur le site professionnels.ign.fr, notamment, voir si l'url associée à votre clef correspond bien au(x) url(s) de déploiement de votre projet.
NB : vous pouvez préciser plusieurs URLs dans le même champ en les séparant par une virgule.

Sinon, il faudrait nous donner plus d'informations sur ce qu'il y a derrière "n'arrive plus à charger l'API IGN" : avez vous des copies d'écran, des messages d'erreur (notamment dans l'onglet réseau des outils de développement votre navigateur) ?

Gilles
30/01/2015, 11h31
kintha

Bonjour,

Voici l'appel qu'on réalise :
init(shapesDesc, apiKey);
})("[{\"srid\": \"3857\", \"borderColor\": \"#000000\", \"fillColor\": \"#FFFF00\", \"wkt\": \"POLYGON((341669.31287888763 6556022.452050107,341669.31287888763 6556061.267728532,341718.87751441635 6556061.267728532,341718.87751441635 6556022.452050107,341669.31287888763 6556022.452050107))\", \"idCartographie\": null, \"idZoneEmprise\": \"\"}]","CLE_WEB"); })()"
2015-01-30T11:26:32 [DEBUG] WebPage - evaluateJavaScript result QVariant(, )
2015-01-30T11:26:32 [DEBUG] WebPage - setupFrame ""

Cette appel est effectuée via PhantomJS.
Et les traces restent bloquées à 2015-01-30T11:26:32 [DEBUG] WebPage - setupFrame ""

Avec l'ancienne clé, il n'y avait pas de bloquage.
Pour info, les URLs dans le portail pro sont correctes.

Merci de votre aide

Pour plus de détail, voici le code JS appelé par notre URL :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function init(zonesEmprisesString, kley) {
	shapesList = JSON.parse(zonesEmprisesString);
	
	// Récupération de la clé API JS depuis le context
	APIKey = kley;
	
	if (checkApiLoading('loadAPI();',['OpenLayers','Geoportal','Geoportal.Viewer','Geoportal.Viewer.Default'])===false) {
		return;
	}
	
	Geoportal.GeoRMHandler.getConfig([APIKey], null,null, {
		onContractsComplete: initMapView
	});
}

Nous n'avons aucun retour !

Merci de votre aide

30/01/2015, 14h29
gcebelieu

Ces traces n'apportent malheureusement pas beaucoup d'éléments.

De ce que je connais de phantomJS, c'est que c'est qu'il permet "d'exécuter des page web" sans navigateur.

Votre clef est sécurisée par referer (url de déploiement de votre page web), ce qui veut dire que les requêtes qui vont partir vers nos webservices depuis votre page vont être traitées ou non si l’entête "referer" qu'elles contiennent correspond bien à une des URLs associées à votre clef. Pour un navigateur "classique", l'entête est remplie avec l'url de déploiement de la page web affichée. Avec PhantomJS, je ne sais pas. Idéalement, il faudrait arriver à tracer les requêtes qui partent vers les serveurs wxs.ign.fr et voir quel referer est transmis et voir aussi les réponses retournées.

Citation:

Pour info, les URLs dans le portail pro sont correctes

Si la seule différence de comportement vient de la clef utilisée, il faut comparer scrupuleusement les deux clefs :

la sécurisation est-elle bien la même ?
les urls déclarées sont elles exactement les mêmes ?
les ressources sollicitées sont elles exactement les mêmes ?
30/01/2015, 16h06
kintha

Citation:

Envoyé par gcebelieu

Si la seule différence de comportement vient de la clef utilisée, il faut comparer scrupuleusement les deux clefs :

la sécurisation est-elle bien la même ?
les urls déclarées sont elles exactement les mêmes ?
les ressources sollicitées sont elles exactement les mêmes ?

Les URLS déclarées sont exactement les mêmes et les conditions d'appel également.
Concernant la sécurisation, que voulait vous dire par là ?

Merci
02/02/2015, 17h22
kintha

Le problème était lié à une couche manquante sur notre clé de prod.
Tout est maintenant résolu.