Implementing WARP

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

Hi everyone,

I've started work implementing the W3C WARP spec[1]; this is currently  
in draft but has remained pretty stable since it was first created. It  
specifies the "access" element of a Widget's config.xml file to  
indicate resources it wants to access, e.g.

<access origin="http://twitter.com" subdomains="true"/>
<access origin="*"/>

In my implementation work, rather than translate these requests into  
global whitelist entries I create an AccessRequest bean tied to the  
specific Widget that requested it. This means that, for example, you  
could grant wildcard access (<access origin="*"/>) for a "safe" RSS  
Reader Widget but not for any others.

I've now written most of the server code for handling this (updates to  
the Proxy service, database scripts, and controllers). At present I  
have it configured that if a Widget is deployed locally using the  
deploy folder, the access request is automatically granted, but for  
those added through the web using the Admin UI it isn't.

However as it stands I haven't done any UI work on this feature and so  
there is currently no way for an administrator to grant or revoke an  
access request through the admin UI.

So, questions:

1. How does this approach sound in general?  What would you like to  
see as the defaults?
2. Does anyone fancy doing some work on the UI to support the feature?

The code I have is basically ready to check in, but wanted some  
feedback before I did so as it has security implications. (It also  
requires adding an additional table in the database schema, which is  
also something I like to give plenty of advance notice for.)

You can review the code here as I've attached a patch:

https://issues.apache.org/jira/browse/WOOKIE-85

S

[1] http://www.w3.org/TR/widgets-access/

Re: Implementing WARP

[Ross Gardler <rg...@apache.org>]

On 23/02/2010 18:01, Ross Gardler wrote:
> On 22/02/2010 22:35, Scott Wilson wrote:
>> 2. Does anyone fancy doing some work on the UI to support the feature?
>
> No ;-)
>
> Seriously I'd love to see this implemented, but don't have the time in
> the forseeable future.

If you have the time to mentor a student in GSoC (assuming we are 
accepted as an org), consider proposing this as a GSoC project.

Ross

Re: Implementing WARP

[Ross Gardler <rg...@apache.org>]

On 22/02/2010 22:35, Scott Wilson wrote:
> Hi everyone,
>
> I've started work implementing the W3C WARP spec[1];

...

> In my implementation work, rather than translate these requests into
> global whitelist entries I create an AccessRequest bean tied to the
> specific Widget that requested it. This means that, for example, you
> could grant wildcard access (<access origin="*"/>) for a "safe" RSS
> Reader Widget but not for any others.
 >
> I've now written most of the server code for handling this (updates to
> the Proxy service, database scripts, and controllers). At present I have
> it configured that if a Widget is deployed locally using the deploy
> folder, the access request is automatically granted, but for those added
> through the web using the Admin UI it isn't.
 >
> However as it stands I haven't done any UI work on this feature and so
> there is currently no way for an administrator to grant or revoke an
> access request through the admin UI.
>
> So, questions:
>
> 1. How does this approach sound in general? What would you like to see
> as the defaults?

Your proposal sounds sensible to me.

> 2. Does anyone fancy doing some work on the UI to support the feature?

No ;-)

Seriously I'd love to see this implemented, but don't have the time in 
the forseeable future.

> The code I have is basically ready to check in, but wanted some feedback
> before I did so as it has security implications. (It also requires
> adding an additional table in the database schema, which is also
> something I like to give plenty of advance notice for.)

Since we currently require "clean-db" in the test environment I don't 
see a problem with adding the DB table without too much warning. Once we 
remove that requirement we need to provide upgrade scripts, for now it 
would be sufficient to document it in the changes doc.

Other than that I think you are good to go.

Ross