views:

56

answers:

2

HTTP Referer is the way I'm doing it at the moment. As everyone who's used this method knows it is not 100% accurate as the Referer header is optional and maybe fiddled with.

Looking at how-to-ensure-access-to-my-web-service-from-my-code-only I'm still undsure of how to go about this in a minimal way.

The situation:

Advertising on someone else's site. Using an iFrame so I can change content/function at will. I pay $x.xx for every time an action is completed. Therefore I need to ensure that the action is being completed from where I said it is allowed to be completed from.

What I'm trying to prevent:

some other webmaster coming along going - "hey that's a nice tool, let me put that on my site" So as i said at the top, what i do atm is if the referer doesn't match I redirect to a page that has the same tool however whatever actions are preformed on that page they don't cost me and money.

While trying to prevent the above, allow the following:

I don't mind if the webmaster/site owner I'm paying cash to for "actions complete" puts the code on other sites - obviously this is a good thing. Lots more coverage, the site owner gets more cash & i get more actions completed, which generates me more cash.

Question

What can I get the other party to do so I know all the requests coming into my web page are from the other party I have an agreement with and not some random.

Thanks :)

info re app

other parties website has an iframe. iFrame displays a html/js/php page of mine that sits on one of my domains. This page uses ajax requests to interact with the actual webservice that is a ruby/sinatra app. I have lots of different pages that fit into the look and feel of the other parties website.

A: 

So I'm thinking some sort of chatter between the other parties server and my server would be a good idea. Then the result of this chatter would be somehow present during the iFrame request.

However I'm not sure if the other party would be able to set a cookie for the domain being served in the iFrame - in fact I'm pretty sure it can't.

Now to get around that limitation I could have a script included as part of the iFrame on the page that could set a cookie.

Ok the above ideas summarised:

  • OtherParty server sends a request to my server gets a response.
  • renders the page with that response as a param to a <script src="...?param"></script>
  • my script sets a cookie
  • as script is before iFrame, script is loaded first
  • iFrame loads with page as a cookie has been set on that domain cookie set before is sent as well
  • bingo, request verified legit

Does this sound ok?

btw my tool that i want action completed on only works if JS is enabled so...

SoreGums
+2  A: 

If you really want to secure who can load your iframe, then one way to do this is via 2-legged OAuth (i.e. have your trusted partner "sign" the iframe GET request). Then your server can grant access based on a cryptographically valid signature and a known signing party. You'll want to enforce relatively short valid lifetimes for the signed requests to prevent someone else from just copying them and embedding them in their own site.

This also gives you the advantage of just having to do an initial, offline key exchange without having your partner making extra server requests of you ahead of the iframe insertion.

Jon Moore
Great, thanks for that info I'll have to have a go at this :)
SoreGums