Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre habitué
    Inscrit en
    mai 2009
    Messages
    191
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 191
    Points : 128
    Points
    128

    Par défaut requête: Cross-site HTTP requests

    À l'heure actuelle, les fonctions de l'API, en particulier la gestion des jetons, utilise la methode de création/effacement re-création d'objets script dans le head du document. C'est pour contourner la limitation "same site policy" de XMLHttpRequest.
    Depuis quelques mois les meilleurs navigateurs - FF, Webkit (Safari et Chrome), Opera - implémente la spécification Cross-Origin Resource Sharing du W3c.
    Si les serveur api.ign.fr et jeton-api.ign.fr renvoyaient le header approprié, cela permettrait d'utiliser XMLHttpRequest et donc une programmation plus propre pour ceux qui ont la chance de travailler sur des projets n'utilisant que des butineurs appropriés (c'est mon cas). Cela permet une meilleure gestion du protocole de jeton, en particulier de ne pas se baser sur l'effet de bord de chargement d'un script par ajout dans le document qui n'est pas spécifié et sujet à caution.

    Bien sûr, il est possible de passer par un proxy, mais c'est une solution insatisfaisante pour d'autres raisons.

    Côté serveur, pour une utilisation sur un nombre d'URL limité, la mise en place est très simple, il suffit de renvoyer un header.
    Selon la politique choisie par l'IGN, il est possible de renvoyer un header permissif pour toute Origin/Referer, ou bien de contrôler la concordance clé/origine (en ajoutant localhost pour le développement, bien sûr).

    Les deux liens suivants sur des pages de mozilladev sont plus explicites que la spécification:
    HTTP access control
    Server-Side Access Control

    Merci d'avance.

    Edit: Si besoin, je me propose en beta-testeur de la fonctionalité, ce qui permet de la restreindre à un petit nombre de clé/origine, dans cette phase.

  2. #2
    Futur Membre du Club
    Profil pro
    Inscrit en
    mai 2009
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2009
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Bonjour,

    Nous sommes confrontés ici à l'éternel problème de requêtes AJAX Cross-Domain...

    Cette contrainte fait polémique depuis de nombreuses années parmi les développeurs WEB. Les récentes spécifiactions Cross-Origin Resource Sharing du W3C et leur implémentation rapide dans les derniers navigateurs montrent bien que la communauté web a besoin de trouver une solution à ce problème.

    Jusqu'à présent de nombreux contournements (Balise script, Iframe, flash, proxy, ...) étaient mis en oeuvre dans le cadre des développements web présentant des API à intégrer dans des pages web tierce (Y compris nos amis de chez Google).

    Ces nouvelles fonctionnalités Cross-Domain sont donc d'un intérêt majeur, et nous nous empresserons de les utiliser (car plus simple, plus propre et plus pérenne) dès lors qu'elles seront supportées par la grande majorité des navigateurs utilisés par les internautes.

    ==> Ceci implique malheureusement d'attendre le lent déclin des navigateurs recalcitrants (qui a dit IE6?) et repousse l'évolution de plusieurs mois, voire années..... :-( Il n'est en effet pas souhaitable de maintenir plusieurs versions de code pour les différents navigateurs (c'est source de bugs et celà représente une surcharge de maintenance importante).

  3. #3
    Membre habitué
    Inscrit en
    mai 2009
    Messages
    191
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 191
    Points : 128
    Points
    128

    Par défaut

    Citation Envoyé par Mr.P. Voir le message
    Ceci implique malheureusement d'attendre le lent déclin des navigateurs recalcitrants (qui a dit IE6?) et repousse l'évolution de plusieurs mois, voire années..... :-( Il n'est en effet pas souhaitable de maintenir plusieurs versions de code pour les différents navigateurs (c'est source de bugs et celà représente une surcharge de maintenance importante).
    Bien sûr, l'évolution de l'API demandera du temps. Ma requête ne concerne pas cette évolution lourde mais seulement l'ajout coté serveur d'un entête permettant l'utilisation du protocole. C'est une modification aisée, sans aucune conséquence pour l'API existante et indispensable pour que les développements spécifiques (code externe à l'API) puissent commencer à utiliser ce nouveau protocole.
    La charge serveur est négligeable, 2 ligne de script serveur sur les requête du serveur api et getToken :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    http://api.ign.fr/geoportail/api?
    http://jeton-api.ign.fr/getToken?

  4. #4
    Membre habitué
    Inscrit en
    mai 2009
    Messages
    191
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 191
    Points : 128
    Points
    128

    Par défaut Silence radio?

    Je comprend mal le silence sur cette question.
    Il ne s'agit pas d'une demande lourde, 2 lignes de code (cf. ci dessous), il n'y a pas de risque de sécurité puisque, de toute façon on accède actuellement aux serveurs sans contrôle de cross-domain depuis l'API, au prix d'une bidouille de manipulation de script.

    Certes, pour le moment la demande est marginale, mais elle va dans le bon sens et ne coûte pas cher.

    Pour info, il suffit d'ajouter coté serveur une ligne de PHP (ou équivalent) pour le serveur api:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    header('Access-Control-Allow-Origin: *');
    Et la même ou bien celle-ci:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    header('Access-Control-Allow-Origin: http://domaine-referer-ok-avec-la-cle.tld');
    pour le serveur de jeton après avoir contrôlé la concordance clé/referer.

    J'ai un RV commercial à l'IGN cette semaine, mais je pense que cet aspect technique sera mal mesuré s'il n'y a pas avant un retour des personnes compétentes vers le bizeness.

  5. #5
    Expert confirmé
    Homme Profil pro
    Ingénieur cartographe
    Inscrit en
    avril 2009
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur cartographe
    Secteur : Service public

    Informations forums :
    Inscription : avril 2009
    Messages : 3 173
    Points : 4 224
    Points
    4 224

    Par défaut Radio-crochets

    La question n'est pas dans la difficulté ou non de la manip, mais de sa légitimité dans notre architecture technique.

    Nous préférons prendre notre temps pour la réflexion plutôt que de sauter sur l'occasion sans avoir les tenants et les aboutissants.

    Nous devons aussi en référer aux RSSI qui doivent donner un avis sur le document W3C en question.

    Bref, nous prenons notre temps.

    A-t-on une idée si les majors du WebMapping (Google, Yahoo and co) ont mis en oeuvre ce mécanisme ?

  6. #6
    Membre habitué
    Inscrit en
    mai 2009
    Messages
    191
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 191
    Points : 128
    Points
    128

    Par défaut

    Je comprend.
    Du coup j'ai bien peur que ça soit long et d'être obligé de revenir à une bidouille.
    Pour le moment ma maquette utilise un proxy, provisoirement, mais c'est pire en perfo et absurde en charge. Si je n'ai pas de visibilité sur l'accès ajax, je serais obligé de laisser tomber…

  7. #7
    Futur Membre du Club
    Profil pro
    Inscrit en
    mai 2009
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2009
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Citation Envoyé par Max_B Voir le message
    Je comprend mal le silence sur cette question.
    Il ne s'agit pas d'une demande lourde, 2 lignes de code (cf. ci dessous), il n'y a pas de risque de sécurité puisque, de toute façon on accède actuellement aux serveurs sans contrôle de cross-domain depuis l'API, au prix d'une bidouille de manipulation de script.
    Les "lenteurs" que vous pouvez ressentir ne sont biensûr pas liées à la complexité technique de la modification proposée. Celle-ci est simplissime à mettre en oeuvre. Voici les vrais points qui nous posent problèmes :

    * La modification proposée permettra aux développeurs web de réaliser "facilement" des pages dans lesquelles l'API du géoportail ne fonctionnera que sur une partie des navigateurs du marché. S'il s'agit d'un site intranet celà ne nous pose pas de problème, mais s'il s'agit de pages publiques celà donnera une mauvaise image de "non-compatibilité" de l'API avec certains navigateurs.

    * Cette amélioration minime ne répond pas à un disfonctionnement du service. Elle serait (si la décision est prise au regard du point 1) synchronisée avec la prochaine livraison du serveur de jeton (mais pour le moment aucune évolution ou correction de ce serveur n'est plannifiée).

  8. #8
    Membre habitué
    Inscrit en
    mai 2009
    Messages
    191
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 191
    Points : 128
    Points
    128

    Par défaut

    Oui, Oui…
    Je vais donc mettre en place une solution différente. Dommage.

    Une remarque hors sujet: comme de nombreux développeurs, je pense qu'il serait bon que les sites soient construit selon l'état de l'art et surtout des standards, mettant à l'index les navigateurs incapables, principalement les différentes mouture de IE.
    Bien sût une évolution récente et non encore standard comme celle dont il est question ici ne rentre pas dans ce cadre.

  9. #9
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2009
    Messages
    1 934
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2009
    Messages : 1 934
    Points : 1 633
    Points
    1 633

    Par défaut "non-compatibilité" de l'API avec certains navigateurs

    Il est malheureusement évident que très peu d'applications et navigateurs respectent les standards. Il est donc illusoire de parler de compatibilité.
    En intranet, outre l'usage de plusieurs navigateurs, on observe l'utilisation de machines virtuelles afin d'offrir l'environnement dans lequel l'application a été validée!
    L'API souffre plus de la comparaison avec Google-Maps et je pense que changer de navigateur n'est pas un frein pour accéder à un véritable service.
    Ce changement de plus permet de bénéficier d'un navigateur un peu plus sur.

  10. #10
    Expert confirmé
    Homme Profil pro
    Ingénieur cartographe
    Inscrit en
    avril 2009
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur cartographe
    Secteur : Service public

    Informations forums :
    Inscription : avril 2009
    Messages : 3 173
    Points : 4 224
    Points
    4 224

    Par défaut Compatibilité ...

    Comment être compatible avec tous les navigateurs quant des experts du domaine passe un temps fou sur le sujet. OpenLayers 2.8 en est à la 6ième release ... et eux, ils sont vraiment bons en Javascript !-)

    On fait au mieux.
    J'ai demandé à mon équipe de regarder si on pouvait monter un prototype avec les en-tête demandés et voir si on peut le faire tester.
    Comme j'ai déjà écrit : il faut être patient!

  11. #11
    Membre habitué
    Inscrit en
    mai 2009
    Messages
    191
    Détails du profil
    Informations forums :
    Inscription : mai 2009
    Messages : 191
    Points : 128
    Points
    128

    Par défaut

    Citation Envoyé par dgrichard Voir le message
    J'ai demandé à mon équipe de regarder si on pouvait monter un prototype avec les en-tête demandés et voir si on peut le faire tester.
    Ah, merci, c'est sympa.
    Je vais donc garder mes xhr et ma bidouille proxy pour le moment, des fois que le protocole soit prêt quand j'en aurai besoin en prod.

Discussions similaires

  1. [AJAX] requête: Cross-site HTTP requests
    Par Aquaa dans le forum AJAX
    Réponses: 1
    Dernier message: 02/03/2010, 11h45
  2. [C#] [WebServices] Http Request et SOAP
    Par Piolet dans le forum Windows Forms
    Réponses: 17
    Dernier message: 02/02/2009, 18h42
  3. redirection http://site => https://site
    Par FiSh MoOn dans le forum Apache
    Réponses: 6
    Dernier message: 27/03/2006, 18h34
  4. Comment envoyer une requête POST via HTTP ?
    Par pdtor dans le forum C++
    Réponses: 2
    Dernier message: 13/09/2005, 06h54
  5. Réponses: 7
    Dernier message: 19/09/2004, 23h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo