You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2011/11/16 11:58:49 UTC
Proxy admin in Wookie
Hi everyone,
I was looking at the requirements for moving from the admin web client to supporting command line and API clients (see https://issues.apache.org/jira/browse/WOOKIE-262), and was wondering about the proxy configuration, which currently uses the Whitelist and AccessRequest objects.
Currently the proxy details are stored in a database and accessed via beans using JPA/JCR, however I was wondering about instead configuring the proxy using a policies text file, and then having a watcher thread monitor the file and reload the settings whenever it is modified.
The "pro" side of this is that for an admin, if you want to change any of the proxy policies all you have to do is edit a text file rather than use commands or a special client.
The "con" side would be that policies end up cached in memory rather than pulled from a DB as needed which may have a performance impact when looking up applicable policies, though we could use JCS (http://commons.apache.org/jcs/) if it turned out to be a problem. Another "con" is that we'd need to write code for reading and updating the text file (with potential for new bugs...)
Below I've put an example of what a policies file might look like.
-S
##
## Access Policies File
##
## This file is dynamically loaded by Wookie and configures
## access policies for the proxy service, including both
## whitelist (global) and widget-specific access policies
##
## Note that when new widgets are added to Wookie their
## access policy requests are automatically added to this
## file.
##
##
## The format of entries is widget-uri origin directive
## The widget-uri and origin may be a wildcard (*). To enable
## subdomains, use a wildcard as the first element of the
## origin host, e.g. http://*.apache.org
##
## The default (implicit) policy is to deny all origins for all widgets
##
## Example:
##
## * http://127.0.0.1 ALLOW
## http://www.getwookie.org/widgets/weather http://newsrss.bbc.co.uk ALLOW
## http://www.getwookie.org/widgets/rss * ALLOW
##
## This set of policies would allow access to 127.0.0.1 for all
## widgets, while the "weather" widget would be allowed to access
## URLs from http://newsrss.bbc.co.uk, and the RSS widget could
## access any URL from any origin.
##
* http://127.0.0.1 ALLOW
Re: Proxy admin in Wookie
Posted by Scott Wilson <sc...@gmail.com>.
On 16 Nov 2011, at 12:33, Paul Sharples wrote:
> On 16/11/2011 10:58, Scott Wilson wrote:
>> Hi everyone,
>>
>> I was looking at the requirements for moving from the admin web client to supporting command line and API clients (see https://issues.apache.org/jira/browse/WOOKIE-262), and was wondering about the proxy configuration, which currently uses the Whitelist and AccessRequest objects.
>>
>> Currently the proxy details are stored in a database and accessed via beans using JPA/JCR, however I was wondering about instead configuring the proxy using a policies text file, and then having a watcher thread monitor the file and reload the settings whenever it is modified.
>>
>> The "pro" side of this is that for an admin, if you want to change any of the proxy policies all you have to do is edit a text file rather than use commands or a special client.
>>
>> The "con" side would be that policies end up cached in memory rather than pulled from a DB as needed which may have a performance impact when looking up applicable policies, though we could use JCS (http://commons.apache.org/jcs/) if it turned out to be a problem. Another "con" is that we'd need to write code for reading and updating the text file (with potential for new bugs...)
> IMO the second one is the main con, checking concurrency issues on modification for example. The whitelist & access requests don't tend to change a great deal really (and up until now at least), we dont seem to have lots of those records in the database by default. I can see the logic in what you propose and your example format below looks (a lot) like a properties file that the apache web server might read on boot. (no bad thing)
Even better, the PropertiesConfiguration class comes with a FileChangedReloadingStrategy that automatically checks for file changes :-)
I've had a good explore now, and think this is doable and quite a lot simpler than our current approach.
The only thing is that going this route it makes a lot more sense to treat the white list and access requests as a single "Policy" class and to have a single REST API rather than two separate ones.
I've uploaded a patch of progress so far...
>
> Paul
>>
>> Below I've put an example of what a policies file might look like.
>>
>> -S
>>
>> ##
>> ## Access Policies File
>> ##
>> ## This file is dynamically loaded by Wookie and configures
>> ## access policies for the proxy service, including both
>> ## whitelist (global) and widget-specific access policies
>> ##
>> ## Note that when new widgets are added to Wookie their
>> ## access policy requests are automatically added to this
>> ## file.
>> ##
>> ##
>> ## The format of entries is widget-uri origin directive
>> ## The widget-uri and origin may be a wildcard (*). To enable
>> ## subdomains, use a wildcard as the first element of the
>> ## origin host, e.g. http://*.apache.org
>> ##
>> ## The default (implicit) policy is to deny all origins for all widgets
>> ##
>> ## Example:
>> ##
>> ## * http://127.0.0.1 ALLOW
>> ## http://www.getwookie.org/widgets/weather http://newsrss.bbc.co.uk ALLOW
>> ## http://www.getwookie.org/widgets/rss * ALLOW
>> ##
>> ## This set of policies would allow access to 127.0.0.1 for all
>> ## widgets, while the "weather" widget would be allowed to access
>> ## URLs from http://newsrss.bbc.co.uk, and the RSS widget could
>> ## access any URL from any origin.
>> ##
>>
>> * http://127.0.0.1 ALLOW
>>
>>
>
Re: Proxy admin in Wookie
Posted by Scott Wilson <sc...@gmail.com>.
On 16 Nov 2011, at 12:33, Paul Sharples wrote:
> On 16/11/2011 10:58, Scott Wilson wrote:
>> Hi everyone,
>>
>> I was looking at the requirements for moving from the admin web client to supporting command line and API clients (see https://issues.apache.org/jira/browse/WOOKIE-262), and was wondering about the proxy configuration, which currently uses the Whitelist and AccessRequest objects.
>>
>> Currently the proxy details are stored in a database and accessed via beans using JPA/JCR, however I was wondering about instead configuring the proxy using a policies text file, and then having a watcher thread monitor the file and reload the settings whenever it is modified.
>>
>> The "pro" side of this is that for an admin, if you want to change any of the proxy policies all you have to do is edit a text file rather than use commands or a special client.
>>
>> The "con" side would be that policies end up cached in memory rather than pulled from a DB as needed which may have a performance impact when looking up applicable policies, though we could use JCS (http://commons.apache.org/jcs/) if it turned out to be a problem. Another "con" is that we'd need to write code for reading and updating the text file (with potential for new bugs...)
> IMO the second one is the main con, checking concurrency issues on modification for example. The whitelist & access requests don't tend to change a great deal really (and up until now at least), we dont seem to have lots of those records in the database by default. I can see the logic in what you propose and your example format below looks (a lot) like a properties file that the apache web server might read on boot. (no bad thing)
>
I've had a go at a prototype, and the standard commons PropertiesConfiguration object works surprisingly well for parsing these sorts of files.
In fact I think the net result would be quite a lot less code (which is good)
> Paul
>>
>> Below I've put an example of what a policies file might look like.
>>
>> -S
>>
>> ##
>> ## Access Policies File
>> ##
>> ## This file is dynamically loaded by Wookie and configures
>> ## access policies for the proxy service, including both
>> ## whitelist (global) and widget-specific access policies
>> ##
>> ## Note that when new widgets are added to Wookie their
>> ## access policy requests are automatically added to this
>> ## file.
>> ##
>> ##
>> ## The format of entries is widget-uri origin directive
>> ## The widget-uri and origin may be a wildcard (*). To enable
>> ## subdomains, use a wildcard as the first element of the
>> ## origin host, e.g. http://*.apache.org
>> ##
>> ## The default (implicit) policy is to deny all origins for all widgets
>> ##
>> ## Example:
>> ##
>> ## * http://127.0.0.1 ALLOW
>> ## http://www.getwookie.org/widgets/weather http://newsrss.bbc.co.uk ALLOW
>> ## http://www.getwookie.org/widgets/rss * ALLOW
>> ##
>> ## This set of policies would allow access to 127.0.0.1 for all
>> ## widgets, while the "weather" widget would be allowed to access
>> ## URLs from http://newsrss.bbc.co.uk, and the RSS widget could
>> ## access any URL from any origin.
>> ##
>>
>> * http://127.0.0.1 ALLOW
>>
>>
>
Re: Proxy admin in Wookie
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 16/11/2011 10:58, Scott Wilson wrote:
> Hi everyone,
>
> I was looking at the requirements for moving from the admin web client to supporting command line and API clients (see https://issues.apache.org/jira/browse/WOOKIE-262), and was wondering about the proxy configuration, which currently uses the Whitelist and AccessRequest objects.
>
> Currently the proxy details are stored in a database and accessed via beans using JPA/JCR, however I was wondering about instead configuring the proxy using a policies text file, and then having a watcher thread monitor the file and reload the settings whenever it is modified.
>
> The "pro" side of this is that for an admin, if you want to change any of the proxy policies all you have to do is edit a text file rather than use commands or a special client.
>
> The "con" side would be that policies end up cached in memory rather than pulled from a DB as needed which may have a performance impact when looking up applicable policies, though we could use JCS (http://commons.apache.org/jcs/) if it turned out to be a problem. Another "con" is that we'd need to write code for reading and updating the text file (with potential for new bugs...)
IMO the second one is the main con, checking concurrency issues on
modification for example. The whitelist & access requests don't tend to
change a great deal really (and up until now at least), we dont seem to
have lots of those records in the database by default. I can see the
logic in what you propose and your example format below looks (a lot)
like a properties file that the apache web server might read on boot.
(no bad thing)
Paul
>
> Below I've put an example of what a policies file might look like.
>
> -S
>
> ##
> ## Access Policies File
> ##
> ## This file is dynamically loaded by Wookie and configures
> ## access policies for the proxy service, including both
> ## whitelist (global) and widget-specific access policies
> ##
> ## Note that when new widgets are added to Wookie their
> ## access policy requests are automatically added to this
> ## file.
> ##
> ##
> ## The format of entries is widget-uri origin directive
> ## The widget-uri and origin may be a wildcard (*). To enable
> ## subdomains, use a wildcard as the first element of the
> ## origin host, e.g. http://*.apache.org
> ##
> ## The default (implicit) policy is to deny all origins for all widgets
> ##
> ## Example:
> ##
> ## * http://127.0.0.1 ALLOW
> ## http://www.getwookie.org/widgets/weather http://newsrss.bbc.co.uk ALLOW
> ## http://www.getwookie.org/widgets/rss * ALLOW
> ##
> ## This set of policies would allow access to 127.0.0.1 for all
> ## widgets, while the "weather" widget would be allowed to access
> ## URLs from http://newsrss.bbc.co.uk, and the RSS widget could
> ## access any URL from any origin.
> ##
>
> * http://127.0.0.1 ALLOW
>
>