AJAX et API

a marqué ce sujet comme résolu.

Bonjour,

J'ai une application Synfony 3. Au sein de cette application il y a certaines routes qui doivent être conçues pour être appelées exclusivement via AJAX. C'est-à-dire qu'un script JS doit envoyer du JSON via AJAX, et récupère aussi du JSON en retour.

Le truc c'est que le code JS qui envoie la requête AJAX peut avoir été écrit par l'utilisateur, i.e. je voudrais donner la possibilité à l'utilisateur d'écrire une espèce d'app pour le site. Un peu comme on peut écrire une app facebook à l'intérieur des pages de facebook, sauf que le code du JS est quand même obligatoirement hébergé chez moi (je ne veux pas que le code JS de l'utilisateur soit / puisse être stocké ailleurs). Il aura bien sûr un moyen d'upload pour balancer son script.

Première question, basique: puis-je récupérer du JSON brut avec l'objet Request de Symfony ? et en passant par le système de formulaire/validation (pour en profiter) est-ce que c'est aussi possible ? Si non, existe-t-il un autre moyen de valider les données envoyées facilement ?

Deuxième question: est-ce que je peux être certain à 100% que les cookies et notamment l'ID de session est envoyé automatiquement quand on fait une requête AJAX ? ET le referer ? ON reste dans le même domaine. Si non alors il faudra que je généralise le point 3 ci-dessous à tous les cas.

Troisième question: je souhaiterais aussi que l'utilisateur puisse tester son script en local (depuis localhost) pour ne pas être obligé de l'uploader sur le site à chaque modification mineure. Pour ce cas il faut donc qu'il ait une API key je suppose, car il n'y aura pas d'ID de session ou de cookie pour l'identifier. Comment est-ce que je peux faire ? J'ai essayé de lire des trucs sur OAuth mais ça n'a pas l'air si simple, et me semble-t-il beaucoup trop complexe pour ce que je veux faire. IL faut quand même que ce soit suffisament secure pour qu'on 1/ne puisse pas voler trop facilement l'API key, et2/que l'utilisateur ne puisse appeler mon API que depuis une page précise de mon site, ou alors depuis localhost pour ses tests; mais surtout pas depuis un quelconque autre site web. J'ai évidemment pensé au referer pour cette dernière vérification mais c'est facilement falsifiable, peut-on faire mieux ?

Pour ne rien vous cacher, c'est pour un jeu. Dans ce cadre il faut absolument que l'utilisateur soit obligé de passer par mon site (sauf pour les tests en localhost). En aucun cas il ne doit pouvoir faire appel à mes API depuis un autre site web (car sinon 1/c'est facile de tricher et 2/plus personne ne viendra chez moi)

Merci pour votre aide.

+1 -0

En aucun cas il ne doit pouvoir faire appel à mes API depuis un autre site

Il y a moyen de bloquer ça dans les serveurs (Bloqué de base je crois), c'est au niveau du cross-domain.

De mémoire, je dirais qu'il est impossible de faire la maniclette avec localhost.

Est-ce que je peux être certain à 100% que les cookies et notamment l'ID de session est envoyé automatiquement quand on fait une requête AJAX ? ET le referer ?

Je dirais que non (En tout cas, il n'est pas du tout sécure de se baser sur le referer. Je pars du principe que le referer sert uniquement à des fins d'analyse et une petite couche de sécurité facilement traversable).

Il faut simplement vérifier côté serveur si toutes les variables nécessaires sont là et sont juste.

[edit]
Et pour tout ce qui concerne Symphony, je suis désolé. Je ne l'ai jamais utilisé.

+2 -0

Salut !

Première question, basique: puis-je récupérer du JSON brut avec l'objet Request de Symfony ? et en passant par le système de formulaire/validation (pour en profiter) est-ce que c'est aussi possible ?

QuentinC

Oui, en récupérant le corps de la requête ($request->getBody() si je me souviens bien, mais ça date de Symfony 2.7).

Deuxième question: est-ce que je peux être certain à 100% que les cookies et notamment l'ID de session est envoyé automatiquement quand on fait une requête AJAX ?

QuentinC

Tu peux très probablement paramétrer ton objet XmlHttpRequest pour avoir systématiquement le cookie dans ce que tu envoies (si tu utilises jQuery, il y a moyen de le faire aussi), si c'est ce que tu appelles "être sûr"  ;)

Pour les questions de domaine source, je ne connais pas assez la chose pour pouvoir te conseiller, malheureusement.

+0 -0

Je ne sais pas si tu peux vraiment bloquer tous les domaines sauf localhost mais une solution simple serait de limiter le nombre de requêtes possibles par jour.

Si par exemple tu bloques à disons 1 000 requêtes par mois, ça rend en pratique impossible de tester + mettre en place un site qui utilise ton api (ou le site devra avoir à peine quelques visiteurs). Et si jamais un testeur à besoin de plus de requêtes tu peux voir au cas par cas pour lever la limite si l'utilisateur te montre le bien fondé de sa demande.

+2 -1

Oui, en récupérant le corps de la requête ($request->getBody() si je me souviens bien, mais ça date de Symfony 2.7).

Il semble que ça ait été renommé $request->getContent(), mais effectivement c'est ça, ça marche :

1
2
<?php
$json = json_decode( $request->getContent() )

Maintneant il y a juste à trouver comment faire pour utiliser l'API de formulaire/validation avec $json… Parce qu'évidemment $form->handleRequest($request) ne marche pas dans ce cas.

Tu peux très probablement paramétrer ton objet XmlHttpRequest pour avoir systématiquement le cookie dans ce que tu envoies (si tu utilises jQuery

J'utilise pas JQuery. Je fais beaucoup mieux et beaucoup plus efficace avec seulement deux dépendences: requirejs et promisejs.

Je ne sais pas si tu peux vraiment bloquer tous les domaines sauf localhost mais une solution simple serait de limiter le nombre de requêtes possibles par jour

Apparament je peux, j'ai trouvé cette doc MDN. Du coup ça résout aussi ma précédente question, pour que les cookies soient envoyés il faut préciser withCredentials=true côté AJAX, et côté serveur je dois renvoyer l'en-tête Access-Control-Allow-Credentials: true.

Par contre ça ne m'empêche pas d'utiliser CURL pour faire une fausse requête en fixant l'en-tête origin à localhost; c'est la même fiabilité que referer.

Une limite de requêtes par jour ou par heure, à voir… c'est vrai que si on fait comme twitter à mettre une limite à 100 par heure, on empêche un site alternatif d'avoir un trafic déraisonnable.

Merci.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte