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
>> 
>> 
> 

Reply via email to