Hi everyone, I've been digging a little deeper on this one, and there are a number of related issues. The problem is that all of the following:
- widget start pages - the admin web interface - the proxy API - the REST APIs - the admin REST APIs ... share a common origin, i.e. wherever Wookie is hosted. This means that if any one of these issues a BASIC AUTH challenge, the browser will cache this and send it to all requests to the same origin. Likewise, if a cookie is set, it will be set for all of these widgets and services. Normally this isn't a problem, as the only cookies will be those set by Wookie itself such as JSessionID. However, if as a result of a request to the proxy a Set-Cookie header is passed, then this will be stored in the browser as being set by the Wookie origin. Not a good idea. There are a couple of solutions I've been thinking of... ==== 1. Use a dynamic origin for each widget instance. Shindig installations sometimes use this - e.g. instead of http://my.server.com/wookie/wservices... the URL for a widget would be http://wgt12131931.my.server.com/wookie/wservices... This can be quite a pain to set up as you need a host configuration that supports it. However it does nicely isolate the widgets so may be a good option for advanced production installations. Its also the only way I can see we could safely support proxied cookies. 2. Use a different, stateless authz method for admin functions We could use a different authz method for accessing admin REST APIs. For example, setting a X-WSSE header with a token. 3. Use a common authz method for all REST APIs but with a permissions model As above, we can use a stateless authz model for all API requests, e.g. using API keys, but add a permissions model. So the special Admin key has permissions for the Admin REST APIs. If we implement signed API requests (see WOOKIE-279) then this also gives us good protection against hijacking API keys. It also solves WOOKIE-214 as rather than having to revoke API keys, we can just generate a new API Secret and leave the data as-is. ==== Thoughts? I'm not sure what any of the above implies for supporting oAuth. -S
