2009-07-14 9 views
4

HTTP Referer est la façon dont je le fais en ce moment. Comme tous ceux qui ont utilisé cette méthode savent que ce n'est pas 100% précis car l'en-tête Referer est optionnel et peut-être bidouillé.Comment s'assurer que les demandes http proviennent d'un emplacement spécifique?

En regardant how-to-ensure-access-to-my-web-service-from-my-code-only Je ne suis toujours pas sûr de la façon de procéder à ce sujet d'une manière minimale.

La situation:

Publicité sur le site de quelqu'un d'autre. Utiliser un iFrame pour pouvoir changer de contenu/fonction à volonté. Je paye x.xx $ pour chaque fois qu'une action est terminée. Par conséquent, je dois m'assurer que l'action est complétée à partir de l'endroit où j'ai dit que l'on peut l'achever.

Ce que je suis en train de prévenir:

un autre webmaster à venir le long d'aller - « hé, c'est un bel outil, laissez-moi mettre ça sur mon site » Donc, comme je l'ai dit en haut, ce je fais atm est si le referer ne correspond pas je redirige vers une page qui a le même outil mais quelles que soient les actions qui sont préformées sur cette page ils ne me coûtent pas d'argent.

Tout en essayant d'éviter ce qui précède que les éléments suivants:

Je ne me dérange pas si le propriétaire webmaster/site Je paie l'argent à des « actions complètes » met le code sur d'autres sites - c'est évidemment une bonne chose. Beaucoup plus de couverture, le propriétaire du site obtient plus d'argent & je reçois plus d'actions complétées, ce qui me génère plus d'argent.

Question

Que puis-je obtenir de l'autre partie à le faire, je connais toutes les demandes à venir dans ma page web sont de l'autre partie, j'ai un accord avec et non pas un hasard.

Merci :)

information re app

autres site Web parties ont un iFrame. iFrame affiche une page html/js/php qui se trouve sur l'un de mes domaines. Cette page utilise des requêtes ajax pour interagir avec le webservice réel qui est une application ruby ​​/ sinatra. J'ai beaucoup de pages différentes qui correspondent à l'apparence du site Web des autres parties. Donc, je pense qu'une sorte de bavardage entre le serveur des autres parties et mon serveur serait une bonne idée. Ensuite, le résultat de ce bavardage serait en quelque sorte présent lors de la requête iFrame.

Cependant, je ne suis pas sûr que l'autre partie serait en mesure de définir un cookie pour le domaine étant servi dans l'iFrame - en fait, je suis sûr que ce ne peut pas. Maintenant, pour contourner cette limitation, je pourrais avoir un script inclus dans le cadre de l'iFrame sur la page qui pourrait définir un cookie.

Ok les idées résumées ci-dessus:

  • serveur OtherParty envoie une requête à mon serveur reçoit une réponse.
  • affiche la page avec cette réponse comme à un param < script src = "...? PARAM" > </script >
  • mon script définit un cookie
  • en tant que script est avant iFrame, le script est chargé en premier
  • charges iFrame avec la page en tant que témoin a été mis sur ce cookie de domaine défini avant l'envoi ainsi
  • bingo, demande légitime vérifiée

Est-ce-que ça sonne bien?

BTW mon outil que je veux des actions terminées effectuées ne fonctionne que si JS est activé si ...

Répondre

3

Si vous voulez vraiment obtenir qui peut charger votre iframe, puis une façon de le faire est par deux pattes OAuth (c'est-à-dire que votre partenaire de confiance "signe" la requête iframe GET). Votre serveur peut alors accorder un accès basé sur une signature cryptographiquement valide et une partie de signature connue. Vous devez appliquer des durées de vie valides relativement courtes pour les demandes signées afin d'empêcher quelqu'un d'autre de simplement les copier et de les intégrer dans leur propre site. Cela vous donne également l'avantage de devoir effectuer un échange initial de clés hors ligne sans que votre partenaire ne vous fasse plus de demandes de serveur avant l'insertion de l'iframe.

+0

Super, merci pour cette info, je vais devoir faire un tour :) – SoreGums

Questions connexes