Proxies, headers, authz and origins in Wookie

[Scott Wilson <sc...@gmail.com>]

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