2

I've created a web widget that displays user specific information from my site. This widget is java script based (I followed this example), and can be embedded in other sites.

I'm looking for a way to control who can embed the widget in his site. Any ideas/references are welcome.

davidrac
  • 10,723
  • 3
  • 39
  • 71

2 Answers2

1

Rather than directly serving the file, you could try using request.referer and only optionally sending the JavaScript file (via a controller action) based on a list of approved web hosts. You can use send_file to conveniently send the JavaScript to the client (set caching options in HTTP header so browsers don't repeatedly ask for the file). However, the referrer can be spoofed and may not be sent depending on HTTPS => HTTP configurations.

You also might consider requiring an API key for your JavaScript file (just append it on as part of the JavaScript file request). While it's not foolproof by any means, it makes tracking usage much more simple. (And by using logs, you may be able to discover non-legit uses).

WiredPrairie
  • 58,954
  • 17
  • 116
  • 143
  • 1
    The API Key approach is a good one for reasons WPCoder stated. While it's visible and thus easily stolen, it's a good start. To truly lock it down there are lots of methods, but the standard these days is OAuth; significantly more complex, but secure, if that's what you really need. – Tom Harrison Oct 21 '12 at 16:28
  • I'm using OAuth for the API part of my system, but isn't it a problem on the client side? Can you point me to a reference? – davidrac Oct 21 '12 at 16:33
  • @tharrison -- I don't understand how you'd use OAuth for this? This is trying to prevent embedding of the javascript widget. – WiredPrairie Oct 21 '12 at 16:47
  • I don't mind if the solution will allow embedding the widget and won't allow it to access my site if I don't want it to. If this is possible with OAuth, can you let me know how? – davidrac Oct 22 '12 at 06:30
  • While this doc is for Google APIs, it's a general OUath solution for JS applications: [Using OUath2 for Client-Side Applications](https://developers.google.com/accounts/docs/OAuth2UserAgent). I think this is likely overkill for your solution, but it's an option (I think!) – Tom Harrison Oct 22 '12 at 12:14
  • Thanks for your comment. I've read about the implicit flow of OAuth 2 and played with it a bit. I've been able to authenticate the user and run queries using only client side code. However, I still can't figure up how to use it as part of a widget solution. Any hints? – davidrac Nov 08 '12 at 09:37
  • Unfortunately, [REFERER is not always present](http://en.wikipedia.org/wiki/HTTP_referer#Referer_hiding) (and easily spoofed for server side requests). – Arjan Dec 15 '12 at 11:28
  • It can work in some scenarios. The question wasn't very detailed. :) The API key would also work, and be far easier to understand and implement for widget embedders. The most reliable solution may be something server side, on the hosting server, rather than entirely on the client. (A proxy). – WiredPrairie Dec 15 '12 at 21:19
0

You have to use some additional tricks along with OAuth in order to positively identify the client.

This question was answered in details in here.

Community
  • 1
  • 1
davidrac
  • 10,723
  • 3
  • 39
  • 71
  • I really think that the answer you accepted there is not secure. Not secure at all. See my comments there. (The steps from the article you've found in the linked question *is* secure, in my opinion, and we're using the same JavaScript trickery. Too bad my answer here was deleted here.) – Arjan Dec 15 '12 at 08:21
  • Thanks for your answers and comments. I have no idea why your answer was deleted. I didn't implement this yet, but I think that the answer I referenced, along with the accompanying comments are valuable. They give a pretty good idea on how to approach this, don't you agree? – davidrac Dec 15 '12 at 11:14
  • I do feel that the article you found is key for your solution, but I don't think that specific answer adds anything to that. Actually, I feel that answer is much worse than the article. (That answer was posted when I had a bounty on your question; I *hope* the answerer just quickly read the article you found, and posted a bad summary to get that bounty, rather than having truly implemented it that way. I reposted my deleted answer at [REST authentication and exposing the API key](http://stackoverflow.com/questions/5472668/rest-authentication-and-exposing-the-api-key/13891103#13891103).) – Arjan Dec 15 '12 at 11:27
  • Thanks. I will add a comment to the original question for now. – davidrac Dec 15 '12 at 11:31
  • New idea: *maybe* CORS can be extended to achieve the same. We've not tried that though; see [my own comment](http://stackoverflow.com/questions/5472668/rest-authentication-and-exposing-the-api-key/13891103#comment19730606_13891103) at my earlier answer. – Arjan Jan 08 '13 at 21:26