J'ai une application iOS dans laquelle l'utilisateur peut effectuer des demandes HTTP à partir de leurs téléphones et que les informations HTTP renvoient sur la base du code postal que l'utilisateur fournit via le téléphone.
Mon problème est que tout le monde peut taper l'URL et le serveur répondrait avec les informations correspondant au code postal qu'ils entrent par exemple Mes questions est, puis-je limiter le serveur pour répondre uniquement aux demandes effectuées à partir de mon application iOS sans l'utilisateur avoir à créer un utilisateur et un mot de passe? En d'autres termes, si quelqu'un types pour la demande HTTP, j'utilise Laravel. Voici mon code de Laravel. Itinéraire: contrôleur: demande: http://example.com/zip-code/78515
Encore une fois, la question est de savoir comment puis-je limiter le serveur pour répondre uniquement aux demandes effectuées à partir de mon application iOS sans que l'utilisateur ait à créer un nom d'utilisateur et un mot de passe? http://example.com/zip-code/78515 . http://example.com/zip-code/78515 directement dans un navigateur, je souhaite que le serveur ignore la demande, mais si la demande vient de mon application iOS, je veux le serveur à réagir en conséquence.
3 Réponses :
Ce paquet semble faire cela
https://github.com/spinen/laravel-Browser-Filter
Fondamentalement, vous ajoutez un middleware qui lit l'agent utilisateur hors de la demande et nie le reste.
Sachez que cela est assez trivial pour vaincre
La demande sera effectuée en code de l'application et non d'un navigateur.
Cela n'a pas vraiment d'importance - les demandes peuvent être fabriquées à partir de n'importe où, les agents d'utilisateurs peuvent être spoofés.
Il n'y a pas de moyen infaillible de répondre uniquement aux demandes effectuées par votre application.
Agent utilisateur Sniffing, la détection des fonctions Navigator et les mesures similaires peuvent dissuader la plupart des tentatives de base pour charger des informations de cette URL (telles que les moteurs de recherche), mais toute personne avec un peu de temps peut apprendre à reproduire les demandes HTTP effectuées par votre application, vaincre ces mesures.
Même nécessitant une connexion n'empêchera pas la demande externe (elles peuvent envoyer des demandes correspondant à votre flux de travail de connexion pour obtenir un jeton valide, puis demandez l'URL restreinte avec elle).
@ BARNYARD - Merci pour l'information. Donc, diriez-vous que s'il n'y a pas d'informations sensibles laissant la demande sans aucune authentification ne serait acceptable? Quel serait le problème potentiel si je le laisse sans authentification?
@Fs_tigre Certaines choses que je peux penser à: 1. Si vous payez pour ces informations (provient d'une API payante ou de quelque chose), alors quelqu'un le prenant sans payer pour votre application (ou voir les annonces dans une application gratuite) serait une préoccuper. 2. Un développeur ombragé prenant votre API pour alimenter sa propre application. 3. Si la réponse à la demande prend des ressources de calcul importantes et que votre coût du serveur varie selon l'utilisation.
Je ne dis pas que je ne dis pas qu'une certaine demande de vérification n'en vaut pas la peine, sotez simplement qu'une personne déterminée peut le contourner.
(via les commentaires) Je ne veux tout simplement pas surcharger le serveur avec des demandes inutiles.
Dans ce cas, il y a une bien meilleure solution. Navires Laravel avec un
Middleware , que vous pouvez utiliser pour limiter le nombre de demandes par minute par IP (ou par utilisateur connecté, s'ils sont authentifiés).Il suffit d'ajouter
papillon: 60,1 au middleware de votre itinéraire et il sera max sur 60 demandes par minute pour une adresse IP particulière. Définissez-le à quelque chose de relativement élevé (une utilisation si normale ne frappe pas), mais cela empêchera des millions de demandes de la même adresse IP d'utiliser trop de ressources.
Merci, je vais chercher à louer à Laravel.
Pourquoi ne pas simplement passer un jeton de votre application iOS dans le cadre de la demande ou des en-têtes, puis vérifiez le jeton sur le serveur avant de permettre une réponse réussie?
Rien que vous ne puissiez faire arrêtera un attaquant déterminé - ils peuvent construire une demande indiscernable, étant donné un savoir-faire technique suffisant. Il peut y avoir des solutions «assez bonnes» qui dissuadent des utilisateurs non techniques curieux avec désinvolture.
@Matticustardais je pensais à quelque chose comme ça, mais je n'étais pas sûr que cela était possible sans utiliser d'authentification. Je vais essayer de trouver plus d'informations sur l'utilisation des jetons. Merci!
@ceejayoz - Je n'ai aucune information sensible, je ne veux tout simplement pas surcharger le serveur avec des demandes inutiles. Quel serait un problème potentiel que je pourrais rencontrer si je le laisse ouvrir sans vérification? Merci
Il existe des solutions pleines que le passeport pouvant gérer une authentification basée sur les jetons. Mais si tout cela est tout ce dont vous avez besoin, je voudrais simplement définir un jeton aléatoire dans votre fichier .env (par exemple,
my_ios_token = m43t7hmg7t435cmg85t3c7 ), appendez le même jeton à votre Demandes d'application iOS, puis validez le jeton reçu de votre contrôleur. Facile et fait. Devrait être suffisamment pour arrêter les demandes aléatoires de données non sensibles.Avez-vous vraiment un problème? Y a-t-il des gens qui frappent les URL de différents navigateurs maintenant? Peut-être faire rien jusqu'à ce que c'est un problème, le "fix" est trivial mais je suppose que vous avez de meilleures choses à faire