views:

117

answers:

1

I want to let users create "apps" (like Facebook apps) for my website, and I'm trying to figure out the best way to make it secure.

  1. I have a REST api
  2. i want to run the user apps in an iframe on my own site (not a safe markup language like FBML)

I was first looking at oAuth but this seems overkill for my solution. The "apps" don't need to be run on external sites or in desktop apps or anything. The user would stay on my site at all times but see the user submitted "app" through the iframe.

So when I call the app the first time through the iframe, I can pass it some variables so it knows which logged in user is using it on my site. It can then use this user session in it's own API calls to customize the display.

If the call is passed in the clear, I don't want someone to be able to intercept the session and impersonate the user.

Does anyone know a good way to do this or good write up on it? Thanks!

A: 

If you have a REST API, you have no need for an iframe, in fact, iframes are considered very poor practice in modern web applications. An iframe would be useful if you have content on an external site that is not easily manipulated with javascript on the client side, or with your application on the server side. This content is usually in the format of an HTML document.

You've already stated that you have a REST API, so you can likely manipulate the data returned by a resource in any way you see fit. For instance, if the resource responds to JSON or XML requests, you could format and organize that data via Javascript from the client (web browser) or you could use your web framework to gather the data from the REST API and manipulate/organize it, making the result available to your application.

In order to secure the data as it is transferred back and forth between the client and the server, you could provide an API Token (lots of sites do this, e.g. Github, Lighthouse, etc.) for each user from the service provider and require users in your application to provide their API Token. The token could be passed in the HTTP headers to the REST service provider separating the token from the request and response data. HTTPS (SSL) is a must for this type of traffic to prevent eavesdropping.

Let me know if this is too general, I could give you a few specific examples.

Patrick Klingemann
Hey Patrick...thanks for the detailed answer. Regarding the iframe, I'm not entirely sure how your suggestion would work...just to clarify: I'm building the framework and I want user submitted apps to be used on my site (not on an external url). So this means I either have to (1) let users upload their own code to run on my server, which is a security risk (2) give them some kind of sandboxed "safe" language to create their own pages, or (3) they run the code on their own site and it appears on mine via an iframe. Facebook currently allows either #2 and #3. Does this change your answer?
Brian Armstrong
Ok, I understand a little better now. Of those 3 options, I definitely think a combination of 2 and 3 most closely follows the way the web is moving (from an evolutionary standpoint). Your users create their own applications and provide REST APIs of the resources their applications provide. Then you provide an Sandboxed API to allow your users to aggregate the services provided by other users. In fact, this is very similar to Yahoo! Pipes http://pipes.yahoo.com/pipes/, an application I haven't used, but I understand the premise. I'm sure there are other examples of this type of thing.
Patrick Klingemann